Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I am maintaining a program that reads records from a Access ’97 table using a Timer. A different program outside my control writes records to this table. So the reading and writing is not synchronized. I am wondering if this could occasionally lead to data corruption. Writing a testing environment is difficult for several reasons. Does someone know the answer to this, so that I can save myself the trouble of writing an emulator?
By “Access 97” I assume you’re referring to old Jet 3.x format MDB files. The locking and concurrency control was weaker in this older MDB format than in the more modern Jet 4.x format, so you’d gain a boost in robustness by abandoning the old format from the 1990s. There is also better support for row-level locking in Jet 4.x, which could have an impact on performance.
But people used to use Jet 3.x tables to simulate queues all the time back in the old days. I don’t recall significant problems that could be traced to data corruption. If that’s what you’re doing we’ve had MSMQ for a long time though, which offers some real benefits, for example greatly reduced network overhead over a Jet table solution.
The most common source of data corruption in Jet MDBs though is a client that dies or loses file server connectivity while holding dirty pages.