MS Access 2003: Can data disappear from records and how do I test for this and prevent it?

Question

Problem and about the database: Data from a record in Access 2003 database has disappeared. This database has 1 backend and 3 frontends, multiple users and is hosted on Citrix. Within this database, we have records of all clients served, ranging in the 1000s.

Background info: The form for client data entry is set up with various subforms, including both a "programs enrolled" subform and a "services" subform. A client can be enrolled in multiple programs. Once enrolled in a program, services can be entered for that program area using the services subform. There are multiple fields in the services subform, one of which is a drop-down field allowing you to choose from the programs a client has been enrolled in (the list is updated for that client whenever he is enrolled in a new program).

The problem details: For one specific record and one specific program area, the program has disappeared from the "programs enrolled" subform and all of the related services have disappeared from the "services" subform for a period of 3 months of data entry. However, other programs and services for this record did not disappear.

Questions: Is the disappearance of data a common Access 2003 problem? Are there tests in place that can be run to see if data is disappearing and catch that data? If so, what are they? If there is specific code involved, what is it? What can be done to prevent the disappearing of data (other than using a different database)?

Answer 1

Is the disappearance of data a common Access 2003 problem?

No. Data in any version of Access does not just disappear without cause. Unless perhaps your database file has been corrupted. More likely you have a design error in your form and/or database schema.

If you have a form/subform based on parent and child tables, make sure you have a relationship established and that you enforce referential integrity on that relationship. That is a standard practice to ensure you can't delete a parent record while you still have at least one related record in the child table.

Based on your description, it's not clear whether the data is missing from your data tables or just not appearing in your subform when you expect to see it. You might want to clarify that point.

Answer 2

As @HansUp says, this is not a common issue. Two things spring to mind:

1. Jet/ACE files do not like to be stored on file servers with replicated file systems unless the file is edited on only one side of the replication synch. That is, if two servers have a replicated volume and you have people connecting to both servers and trying to edit both copies of the database, you'll hose the data. If you're editing on only one side, there shouldn't be any issues, but I worry about this kind of thing. Another issue might be virtualization, though I don't have any definite scenario where that could be a problem.

2. More than 10 years ago I saw an issue that combined the old bookmark bug with On Error Resume Next that caused data to not be saved. What was happening was that turning off error reporting/handling with the On Error Resume Next was not properly going out of scope, and errors that were occuring in the departure from a record via bookmark navigation were never being reported. The result was that edits were lost. When I changed the bookmark navigation to save the record if it was dirty before changing the bookmark pointer, the problem went away. But while I was at it, I eliminated as many On Error Resume Next statements as possible.

Another guise of the second problem would be if DoCmd.SetWarnings is set to False. I never bother with SetWarnings, so it's not an issue, but it's a common novice technique, and worth looking at. The idea is that errors are happening but the report of them is not getting to the users, and thus, the edits are being lost.

I don't consider either of these very likely, but your situation is so uncommon that even unusual things like these are worth looking at.

Answer 3

At this point, we have determined that the missing data occurs at random and is not traceable to a specific pattern which makes it rather difficult to pinpoint a solution. We are still uncertain if the data actually disappeared or if the user assumed he had entered the data but had not. Unfortunately, our db host does not keep a series of backups that we could trace back to, but rather updates the backup at the end of each day--again raising a problem for tracing the disappearance. We will continue to investigate the various answers provided here and are grateful for your great input and suggestions.