问题和关于数据库：Access 2003 数据库中记录的数据已消失。该数据库有 1 个后端和 3 个前端、多个用户并托管在 Citrix 上。在这个数据库中，我们有所有服务客户的记录，范围在 1000 多个。
背景信息：客户数据输入表单设置有各种子表单，包括“已注册程序”子表单和“服务”子表单。一个客户可以注册多个项目。一旦注册了一个程序，就可以使用服务子表单为该程序区域输入服务。服务子表单中有多个字段，其中一个是下拉字段，允许您从客户已注册的计划中进行选择（只要客户注册新计划，该列表就会更新）。
问题详情：对于一个特定的记录和一个特定的程序领域，该程序已从“已注册的程序”子表中消失，并且所有相关服务已从“服务”子表中消失，为期 3 个月的数据输入。但是，该记录的其他程序和服务并没有消失。
问题：数据消失是 Access 2003 的常见问题吗？是否有可以运行的测试来查看数据是否正在消失并捕获该数据？如果是这样，它们是什么？如果涉及特定代码，它是什么？可以做些什么来防止数据消失（除了使用不同的数据库）？
正如@HansUp 所说，这不是一个常见问题。有两件事浮现在脑海：
Jet/ACE 文件不喜欢存储在具有复制文件系统的文件服务器上，除非文件仅在复制同步的一侧进行编辑。也就是说，如果两台服务器都有一个复制卷，并且有人连接到两台服务器并尝试编辑数据库的两个副本，那么您将使用软管处理数据。如果你只编辑一侧，应该没有任何问题，但我担心这种事情。另一个问题可能是虚拟化，尽管我没有任何确定的情况可能会出现问题。
10 多年前，我看到一个将旧的书签错误与 On Error Resume Next 结合在一起的问题，导致数据无法保存。发生的情况是，使用 On Error Resume Next 关闭错误报告/处理没有正确超出范围，并且从未报告通过书签导航偏离记录时发生的错误。结果是编辑丢失了。当我在更改书签指针之前更改书签导航以保存记录是否脏时，问题就消失了。但是，当我这样做时，我尽可能多地消除了 On Error Resume Next 语句。
第二个问题的另一个伪装是 DoCmd.SetWarnings 是否设置为 False。我从不打扰 SetWarnings，所以这不是问题，但它是一种常见的新手技术，值得一看。这个想法是错误正在发生，但它们的报告没有传达给用户，因此编辑正在丢失。
我认为这两种情况都不太可能，但是您的情况是如此罕见，以至于即使是此类不寻常的事情也值得一看。
数据消失是 Access 2003 的常见问题吗？
不会。任何版本的 Access 中的数据都不会无故消失。除非您的数据库文件已损坏。您的表单和/或数据库架构中更有可能存在设计错误。
如果您有一个基于父表和子表的表单/子表单，请确保您已建立关系并对该关系强制执行参照完整性。这是一种标准做法，可确保您在子表中仍有至少一个相关记录时无法删除父记录。
根据您的描述，尚不清楚您的数据表中是否缺少数据，或者只是在您希望看到它时没有出现在您的子表单中。您可能想澄清这一点。
在这一点上，我们已经确定丢失的数据是随机发生的，并且无法追溯到特定模式，这使得确定解决方案相当困难。我们仍然不确定数据是否真的消失了，或者用户是否认为他已经输入了数据但没有。不幸的是，我们的数据库主机没有保留一系列我们可以追溯的备份，而是在每天结束时更新备份——这再次引发了追踪消失的问题。我们将继续调查此处提供的各种答案，并感谢您的宝贵意见和建议。