تخریب ( Corruption ) در موقعی رخ میده که ساختار باینری فایل به هم بریزه .

در این حالت یا فایل به صورت کامل غیر قابل استفاده میشه و یا اینکه به صورت رندوم خطاهایی رو با خودش به همراه میاره .

از اونجایی که فایل به صورت یک تک فایله , ممکنه در صورت تخریب , شما تمامی فایل رو از دست بدید .
تخریب فایلهای اکسس یه امر عمومیه , اگر چه خود اکسس برخی از خطاهای جزئی رو در هنگام خوندن و نوشتن بر روی جداول پوشش میده .
بنا بر این در اغلب موارد فایل شما تخریب میشه ولی شما از اون مطلع نمیشید .

این امر میتونه خیلی خطرناک باشه . چرا که خطاها به مرور افزایش پیدا میکنن و به در گذر زمان به خطاهایی جدی تر و خطرناک تر تبدیل میشن . تا جایی که عملاً بازیابی رو غیر ممکن و یا بسیار سخت میکنن , که حتی در حالت دوم هم نباید به بازیافت 100% فایل امیدوار باشید .

در اینجا به بررسی برخی موارد که میتونه منجر به تخریب فایل بشه میپردازیم :

نقص در سخت افزار :

عمده نقص سخت افزاری رو میشه در هارد دیسک و کارت شبکه جستجو کرد .

یک هارد بد سکتور بیشتر از هر سخت افزار دیگه ای علاقه منده که فایل شما رو با نقص مواجه کنه . کارت شبکه ای هم که در بخش ارسال Packet ها با اشکال مواجه باشه میتونه در صورتی که فایل شما از طریق شبکه به اشتراک گذاشته شده , اون رو با خطراتی جدی مواجه کنه .
متاسفانه Jet Database به Crash سیستم بسیار حساس بوده و کوچکترین خطایی رو در این بخش به سادگی از کنارش نمیگذره .
Jet بر مبنای file-system کار میکنه و عملاً هر گونه Crash , منجر به توقف در عملیات نوشتن و خوندن توسط اون میشه .
( یکی از مزیتهای SQL Server و یا سیستمهای مبتی بر Client Server در همین بخشه )

تداخل نرم افزاری :

استفاده از Add-Ins ها و ActiveX هایی که از ساختار طراحی دقیقی برخوردار نیستند واجرای اونها با خطا مواجه میشه , میتونه در تخریب خود فایل اکسس نقش موثری داشته باشه .
به خاطر داشته باشید که اونها همون فضایی رو از حافظه استفاد میکنن که Access به اونها اختصاص داده , پس نقص در اونها , منجر به نقص در خود Access هم میشه .

تداخل بین نسخه های مختلف JET :

خود JET دارای نسخه های متفاوتی هستش و به مرور مورد بازبینی و تکمیل قرار گرفته . به اشتراک گذاری یک فایل بین سیستمهایی که دارای نسخه های متفاوتی از JET هستند میتونه منجر به تخریب جزئی تا کلی در فایل بشه .

دسترسی چند گانه به فایل :

JET یک سیستم مبتی بر فایل میباشد ( بر خلاف SQL Sever که بر اساس Client-Server است )
JET جهت استفاده چند کاربر از یک فایل , از یک فایل قفل استفاده میکنه تا بدین وسیله بتونه هماهنگی لازم رو در هنگام نوشتن و خوندن اعمال کنه .
در هنگام اجرای فایل در داخل شبکه با توجه به بار ترافیکی شبکه در صورت ارسال پیغام Time Out از سوی شبکه , دستور در حالت معلق باقی میمونه . در اینگونه موارد فایل نیاز به Repair داره که متاسفانه در اغلب موارد این کار به درستی به انجام نمیرسه .
تا حد امکان از به اشتراک گذاری یک فایل بین چند کاربر , جداً خودداری کنید . در صورت الزام , حتماً اون رو در حالت Front End و Back End طراحی کنید

باگهای موجود در Access و JET

مطمئناً محصولات Microsoft هم خالی از نقص نیستند . بسیاری از خطاها پس از عرضه محصول به بازار آشکار میشه . عمده ترین دلیل عرضه Service Pack ها هم همین آشکار شدن نقائص موجود در داخل برنامه ها هستش .

طراحی ناقص و بی کفایت برنامه

در حالت استفاده از یک فایل در شبکه نیاز به تغییراتی در روال طراحی وجود داره که عملاً در صورت عدم توجه به اونها میتونیم پتانسیل تخریب فایل رو تا حد زیادی بالا ببریم .


قطع برق

قطع برق یکی از مواردی هستش که فایلهای Access به اون خیلی حساسند . خاموش کردن کامپیوتر بدون بستن فایل هم میتونه به همون اندازه مشکل ساز بوده باشه .

کمبود فضا بر روی Hard

در صورتی که فایل اکسس در هنگام اجرا با کمبود فضا مواجه بشه , این امر میتونه فایل رو در معرض یک خطر جدی قرار بده .

خب با این توضیحات میریم سراغ بحث دوم

راههای جلوگیری از تخریب :

نصب آخرین Service Pack و Hotfix ها جهت Access و JET

گزینه Name AutoCorrect رو غیر فعال کنید . این امکان اضافه شده به Access از همون ابتدا در کنار مزایای نسبی خودش مشکلاتی رو هم به همراه آورد .
این امکان هنوز در مراحل تکمیل قرار داره . موجب کاهش کارایی میشه و در تخریب فایل دست داره .

در داخل Subform های مبتنی بر Query اقدام به مخفی کردن فیلدهای مرتبط با foreign key ها نمایید

هرگز به صورت همزمان چند توسعه گر اقدام به تغییر و طراحی یک فایل نکنند

هرگز اقدام به ویرایش کدهای برنامه در هنگام اجرای اون نکنید

از کنار اولین خطای به نمایش در اومده از سوی اکسس به سادگی نگذرید . شاید این آخرین شانس شما برای Backup گیری , Compile , Compact و یا Repair نمودن فایل بوده باشه

اگه فایل Access دچار مشکل شد , اجازه Repair اتوماتیک رو به اون ندید ( معمولاً اقدام به نمایش یک کادر در این خصوص میکنه ) , فایل ldb موجود در کنار فایل اصلی رو پاک کنید . از فایل اصلی یه کپی بگیرید و مجدداً اون رو باز و Compact/Repair رو اجرا کنید

در کدهای برنامه , هر آبجکتی رو که باز میکنید مجدداً ببندیدش . به طور مثال در مورد OpenRecordset ها , حتماً پس از اتمام کار اونها رو Close کنید

فراخوانی توابع API رو با دقت انجام بدید . روالهای کنترل خطای اونها در دست Access نیست .

فایل رو در دو بخش ایجاد کنید , اطلاعات و جداول در داخل یک فایل ( Back End ) و مابقی آبجکتها در داخل فایلی دیگه ( Front End )

فایل رو در فرمت MDE تحویل کاربر نهایی بدید

تا وقتی که الزامی وجود نداره گزینه Record-Level Locking رو در حالت عدم انتخاب قرار بدید

تذکر :

در تاپیکهای بعدی سعی میکنم که بعضی از سرفصلهای اشاره شده رو باز تر کنم تا قابل درک تر باشن .