由于数据库被破坏的趋势,有一种流行的观点认为Access是一个不可靠的后端数据库,用于并发使用,特别是对于20多个并发用户.
有一个少数意见认为Access数据库后端非常稳定和高效,前提是:
我的问题非常具体:"正确编写程序"是什么意思？ 为了防止数据库被破坏,您必须遵循哪些要求？
编辑:要清楚:数据库已经拆分.假设少于25个用户.我对性能考虑不感兴趣,只对数据库稳定性感兴趣.
如果您正在寻找需要避免的编程实践的很好的示例,列表中的第一个通常是不运行拆分数据库.第二个不是将前端放在每台计算机上.
例如,上面的海报有各种各样的问题,但你可以打赌他们的失败是他们没有分割数据,或者他们没有将软件(前端)放在每台计算机上.
至于那个不得不诉诸一些奇怪的锁定机制的人,这有点奇怪而且不是必需的.Access(实际上是JET数据引擎,现在称为ACE)自Office 2000发布以来就内置了行锁定功能.
我已经在商业上部署了大约12年的书面访问应用程序.在那些年里,我有一个客户腐败.
请记住,在Microsoft开始推销和销售SQL服务器之前,他们为大约50个用户评估了JET数据库引擎.虽然我的客户没有问题,但在有人使用probem的10个案例中,有9个案例中您发现列表中的第一个是他们未能拆分数据库,或者他们没有在每台计算机上安装前端.
至于编码技巧或提示？您构建的任何程序设计都可以将少量记录加载到表单中,这是您设计的一个良好开端.换句话说,你永远不想只是简单地抛出附加到大表的表单而不限制要加载到表单中的记录.这可能是我在这里可以给出的头号提示.
例如,将每个人的帐号加载到一台即时柜员机是没有意义的,然后询问用户要使用的帐号.事实上,我问过一位80岁的祖母,如果这个想法有意义的话,甚至她都能解决这个问题.要求用户使用哪个帐户,然后只需加载一个客户就更有意义了.
以上相同的概念适用于网络上的拆分数据库.如果您向用户询问客户帐号,然后将表单打开到带有where子句的一条记录,那么即使后端有100,000条记录,表单加载时间也会接近即时,因为只有一条记录将是从客户表中拖出网络线.
还要记住,市场上有很多商业应用程序,例如使用喷射后端的简单会计(你实际上可以简单地打开具有MS访问权限的会计文件,他们重命名扩展来隐藏这个事实,但它是访问mdb文件).
我的一些客户有3-5个使用耳机的用户,他们整天都在运行我的预订软件.许多人已经预订了超过40,000多名客户,在10年的时间里,他们中的任何一个都没有进行过调查.(上面的一个腐败示例实际上是在单个用户系统上信不信由你).
因此,由于我的访问产品的可靠性,我从未接到过一次服务电话.另一方面,这个应用程序只有160个表单,大约30,000行代码.它有大约65个高度相关和统一的表(强制执行关系,还有级联删除).
因此,对于多用户应用程序,此处不需要特定的编程方法,例外是可以降低带宽要求的良好设计.
在一天结束时,事实证明好的应用程序是不会将不必要的记录加载到表单中的应用程序.事实证明,当您以这种方式设计应用程序时,当您将后端部分更改为SQL服务器时,您会发现这种方法只需要很少的工作就可以使您的访问前端在SQL服务器后端工作得很好.
最后我认为这是对全球近1亿接入用户的估计.Access是迄今为止最受欢迎的桌面数据库引擎,并且大多数用户发现它们无法自由操作.
在网络上遇到操作问题的唯一人是那些没有拆分的人,而不是将前端放在每台计算机上.
到目前为止，唯一令人信服的答案似乎是减少网络流量，并确保您的硬件不会出现故障。
由于多种原因，我发现这些答案并不令人满意。
网络流量位置是矛盾的。如果数据库只能处理一定量的网络流量，那么人们需要合理的指导方针来衡量这一点，以便他们可以明智地选择合适的数据库。
将 Access 数据库崩溃归咎于硬件故障并不是一个站得住脚的立场。用户会（正确地）声称他们的其他软件不会遇到此类问题。
Access 数据库损坏并不是想象中的问题。人们经常建议 5 到 20 个用户是 Access 应用程序的实际上限，这是根据经验得出的结论。