我有一个ACCDB，我前一段时间拆分，其中包含许多带有子表单的表单（基于表格）和BE中的200多个表格（几乎所有表格都是车辆对象的查找表格）和400多个查询。还碰巧存在另一个ACCDB，其中有一个表，其中有6.5M行，FE链接到基本历史信息。两个后端不以任何方式相互链接。 FE为14MB，BE为1.2G，单表DB为900MB，所有主键和索引都设置得恰当。 DB是100％标准化的。 BE每个月都会增长5％。该数据库目前将在今年晚些时候迁移到Oracle 11G环境。
问题： 我最近发现，如果我压缩并修复后端或前端，那么任何包含子形状的形式都不会打开;整个FE只是冻结成白色。即使所有3个都被修复，我仍然有问题。但是如果我压缩/修复所有3 以及将整个前端重新连接到两个后端，则表格突然开始工作。直到最近才开始这种行为。
为什么我必须重新链接才能使表单再次运行？
答案 0 :(得分：2)
在C + R之后，您不必在此处重新链接任何内容。
唯一想到的是，正在进行C + R的用户在发生C + R的文件夹或目录中具有一些限制权限。
请记住，当用户执行C + R时，会创建文件的COPY - 因此可能会在创建新文件时继承CURRENT用户的权限。因此，听起来文件夹上存在一些权限问题，或者正在执行C + R的用户具有一些特殊（不同）权限。 （也许某些继承权限会对某些安全组的成员资格产生影响）。
当然应该确保使用UNC路径名，当然前端需要放在每台机器上。
执行C + R的用户可能再次具有“不同的”驱动器映射，因此由于不同的驱动器号而导致到后端数据库的链接是错误的。所以，如果还没有，作为一般规则，我会强烈避免驱动器号并使用NC路径名（如果你还没有）。
如果您使用的是UNC路径名，那么可能的问题就是权限。
执行C + R的新用户还有可能从“非”受信任位置运行前端。
另外，650万行的表似乎有点大，我假设1.2 Gig大小在C + R之后是正确的？ （但这个问题是另一篇文章）。
这表明驱动器映射问题，权限问题，或者启动应用程序的用户可能会搞乱引用。我将旁路转移到应用程序中，并确保执行C + R的用户可以编译应用程序，并且将从VBA编辑器中小心地注意，例如，办公室14引用不是高举到办公室15引用。
答案 1 :(得分：0)
您已经无法轻松到达＆＃34;无忧无虑的＆＃34;作为数据库的Access的可行性（与＃34;记录的＃34;）相反。记住需要编译的查询，这意味着解析所有表链接，并验证现有索引和其他元数据。通过手动使用链接表管理器简单地覆盖这些信息可能会更有效。
这里有一些可能会帮助你的规定技巧： http://office.microsoft.com/en-gb/access-help/improve-performance-of-an-access-database-HP005187453.aspx
还有一些...... http://www.fmsinc.com/MicrosoftAccess/Performance.html#Linked%20Tables
来自此网站的相关主题： Proper way to program a Microsoft Access Backend Database in a Multiuser Environment
可能对您没有帮助的问题：
正如第二个链接所暗示的那样，事实上有很多变量在起作用，解决这个问题需要一些修改，试用和试验。错误发挥了重要作用。
所有这些，或者你可以升级到SQL Server Express :) http://office.microsoft.com/en-gb/access-help/move-access-data-to-a-sql-server-database-by-using-the-upsizing-wizard-HA010275537.aspx