代码之家  ›  专栏  ›  技术社区  ›  hughdbrown

在多用户环境中编程Microsoft Access后端数据库的正确方法

  •  4
  • hughdbrown  · 技术社区  · 7 年前

    1. 您正确地编写了程序。

    我的问题非常具体: 为了防止数据库损坏,您必须遵循哪些要求?

    编辑: 要明确的是: 数据库已被拆分。假设少于25个用户。我对性能方面的考虑不感兴趣,只对数据库稳定性感兴趣。

    6 回复  |  直到 16 年前
        1
  •  5
  •   onedaywhen    16 年前

    如果您正在寻找需要避免的编程实践的好例子,那么列表中的第一个通常是不运行拆分数据库。第二,不要把前端放在每台计算机上。

    例如,上面的海报有各种各样的问题,但你可以打赌,他们的失败要么是因为他们没有分割数据,要么是因为他们没有在每台计算机上安装软件(前端)。

    对于那些不得不求助于某种奇怪的锁定机制的人来说,这有点奇怪,也不是必需的。Access(实际上是JET数据引擎,现在称为ACE)自Office2000问世以来就内置了行锁定功能。

    我已经在商业上部署应用程序写访问大约12年了。在所有这些年里,我有一个客户发生了一次腐败。

    请记住,在微软开始推广和销售SQL server之前,他们对JET数据库引擎进行了大约50个用户的评级。虽然我的客户没有问题,但在10个案例中,有9个案例中,当有人出现问题时,你会发现列表中的第一个问题是他们未能拆分数据库,或者他们没有在每台计算机上安装前端。

    至于编码技术或技巧?您构建并制作的任何程序设计(其中减少了加载到表单中的记录数)都是您设计的一个良好开端。换句话说,您永远不希望只是简单地抛出一个附在大表上的表单,而不限制要加载到表单中的记录。这可能是我能给你的第一个建议。

    例如,用Everybody的帐号加载一台即时取款机,然后询问用户使用哪个帐号是没有意义的。事实上,我问一位80岁的祖母这个想法是否有意义,甚至她也能理解。询问用户使用哪个帐户,然后简单地加载一个客户,这样做更有意义。

    上述相同的概念适用于网络上的拆分数据库。如果您向用户请求客户帐号,然后将表单打开到带有where子句的一条记录,那么即使后端有100000条记录,表单加载时间也几乎是即时的,因为只有一条记录会从customers表沿网络线向下拖动。

    还要记住,市场上有很多商业应用程序,例如使用jet后端的simply accounting(您实际上可以使用MS access打开simply accounting文件,他们重命名了扩展名以隐藏这一事实,但它是access mdb文件)。

    我的一些客户有3-5个戴着耳机的用户,他们整天都在运行我的预订软件。许多人已经预订了超过40000多个客户,在10年的时间里,没有一个出现问题。(上面的一个腐败示例实际上是在单用户系统上的,信不信由你)。

    因此,对于多用户应用程序,这里不需要特殊的编程方法,只有减少带宽需求的良好设计例外。

    最后一次统计,我想这里估计全球有近1亿访问用户。Access是迄今为止最流行的桌面数据库引擎,大多数用户发现他们的操作没有问题。

    唯一在网络上有操作问题的人是那些没有拆分、没有在每台计算机上放置前端的人。

        2
  •  1
  •   hughdbrown    16 年前

    到目前为止,唯一令人信服的答案似乎是减少网络流量,并确保您的硬件不会出现故障。

    1. 网络流量的位置是矛盾的。如果数据库只能处理一定数量的网络流量,那么人们需要明智的指导方针来衡量这一点,以便能够智能地选择合适的数据库。

    2. 将Access数据库崩溃归咎于硬件故障不是一个合理的立场。用户会(正确地)声称他们的其他软件没有遇到此类问题。

    Access数据库损坏不是想象中的问题。经常建议5到20个用户是访问应用程序的实际上限的人是根据经验说话的。

        3
  •  1
  •   onedaywhen    16 年前

    Corrupt Microsoft Access MDBs FAQ 这些年来,我根据新闻组的帖子编辑了这本书,它比艾伦的网页早。也就是说,这些年来,我的客户几乎没有发生过腐败,从未丢失过数据,也不需要从备份中恢复。

    我不确定在这种情况下“正确编写程序”是什么意思。我读过一些帖子指出这一点,但更多的是实现方面。正如Albert指出的,您必须拆分数据库,并为每个用户提供自己的FE MDB/MDE副本。您无法通过无线网卡访问后端MDB,因为它们太不稳定。与WAN相同,除非WAN非常快/宽且非常稳定。然后,我们建议升级到SQL Server或使用终端服务/Citrix。

        4
  •  1
  •   Rx_    15 年前

    非常好的代码(包装在带有回滚的传输中)我们有一个呼叫中心,在Access 97天的时间里,有超过100个非常活跃的用户。 另一个是带有VB 5前端的Access Jet,它位于便携式设备上,可以连接到SQL Server 6数据库(是的,在过去的拨号时代),有250个并发用户。

    使用向导将表单直接链接到用于编辑表单的表的人员。。。可能是个问题。

        5
  •  0
  •   Jabin    9 年前

    未完成的事务(例如记录集未正确关闭)以及数据库打开时由于任何原因导致的网络连接中断(已看到NIC的节能功能导致损坏)是我的首要原因

        6
  •  -2
  •   Eric    11 年前

    我不认为MS Access Jet Engine的用户数量是一个限制。 我的理解是,Jet引擎将并发维护事务排队,一次应用一个事务(就像打印机队列打印打印作业一样)。通过ODBC连接和智能用户应用程序,管理记录集大小,锁定打开编辑的记录,并仅保持足够长的DB连接以检索记录和保存记录,这对jet引擎几乎没有压力。我将mdb文件视为表。可以想象,在一个或多个数据库中有100个这样的数据库。对这些表的SQL查询将通过随机访问进行,mdb文件的命名约定允许在应用程序中构建SQL查询来访问哪个表(mdb文件)。通过这种方式,MS Access数据库可以达到10s、100s或1000s的千兆字节,并且运行平稳。正确索引和规范化数据以避免存储冗余数据也有帮助。在MS Access和ODBC以及Win32 Perl GUI界面驱动应用程序时,我从未遇到过数据库崩溃或并发问题。除了表、索引和视图/查询之外,我不使用MS Access对象。是的,我将数据库存储在专用PC上,并在每台工作站PC上安装我的应用软件。

    推荐文章