در زمان راه‌اندازی شبکه، ممکن است اطلاعات نسخه تک‌کاربره Access به SQL Server منتقل شود، اما برخی کارکنان همچنان میانبر قبلی را اجرا کنند. اگر طی چند روز روی هر دو بانک اطلاعاتی سند ثبت شود، دیگر با یک به‌روزرسانی ساده یا کپی‌کردن فایل نمی‌توان فرض کرد که همه معاملات در یک دفتر واحد هستند.
مسئله چگونه ایجاد می‌شود؟
فرض کنید تا پایان شنبه تمام اطلاعات به SQL منتقل شده است. روز یکشنبه مسئول صندوق با SQL کار می‌کند، اما مسئول خرید تا چهارشنبه همچنان از مسیر قدیمی Access سند می‌زند. اکنون دو مجموعه ثبت جدید داریم که ممکن است شماره سند، حساب مشتری، ورود یا خروج آب‌شده و اطلاعات تسویه آن‌ها با هم تداخل پیدا کنند.
ترتیب صحیح بررسی
- ثبت سند را موقتاً در هر دو مسیر متوقف کنید تا اختلاف بیشتر نشود و مشخص شود کدام پایگاه داده، نسخه عملیاتی رسمی مجموعه است.
- از هر دو بانک، با ابزار و روش مناسب همان نسخه، نسخه پشتیبان مستقل بگیرید. بانک قدیمی را پاک نکنید و روی فایل‌های آن بازنویسی انجام ندهید.
- تاریخ و ساعت انتقال اولیه به SQL را مشخص کنید. فهرست معاملات ثبت‌شده بعد از آن زمان را در Access و SQL جداگانه تهیه کنید.
- برای تطبیق، تنها شماره سند کافی نیست؛ نوع عملیات، طرف‌حساب، تاریخ، مبلغ، وزن، عیار، شماره انگ، تعداد سکه و وضعیت تسویه را نیز مقایسه کنید.
- مشخص کنید کدام اسناد فقط در Access، کدام فقط در SQL و کدام در هر دو وجود دارند. اسناد وابسته به حواله یا اپلیکیشن را جدا علامت بزنید.
- برنامه را به‌گونه‌ای تنظیم کنید که کارکنان پس از رفع مشکل فقط به بانک اصلی متصل شوند؛ میانبر یا مسیر قدیمی باید به‌روشنی از دسترس استفاده روزمره کنار گذاشته شود.
چرا بازگرداندن یک نسخه پشتیبان مسئله را الزاماً حل نمی‌کند؟
بازیابی نسخه قدیمی روی بانک جدید ممکن است ثبت‌های سالم روزهای اخیر SQL را حذف کند. از طرف دیگر، انتقال دوباره کامل Access روی SQL می‌تواند معاملات مشترک را تکراری کند یا تاریخچه را به حالت قبلی برگرداند. در منابع مورد بررسی، روش خودکار و تأییدشده‌ای برای ادغام دو بانکِ جداشده در این وضعیت ارائه نشده است؛ بنابراین هیچ دستورالعمل حذف دیتابیس یا اجرای انتقال دوباره عمومی توصیه نمی‌شود.
نمونه جدول کنترل
| وضعیت یک معامله | اقدام بررسی |
|---|---|
| فقط در Access ثبت شده | مشخصات و اثر آن بر صندوق و حساب شخص را مستند و برای انتقال کنترل‌شده آماده کنید |
| فقط در SQL ثبت شده | نسخه صحیح را حفظ کنید و از بازنویسی آن جلوگیری کنید |
| در هر دو ثبت شده | تطبیق کنید تکرار واقعی است یا دو رویداد متفاوت با مشخصات مشابه |
| دارای حواله، چک، API یا اتصال خارجی | وابستگی‌های سند را قبل از هر اصلاح بررسی کنید |
نتیجه: تشخیص و ادغام این وضعیت باید زیر نظر مسئول فنی آشنا با ساختار بانک ته‌حساب و پس از تهیه پشتیبان‌های آزمایشی انجام شود. در نرم‌افزار حسابداری، «جایگزین‌کردن دیتابیس» با «انتقال ایمن اسناد جدید» یک عملیات واحد نیست.