在 ACCESS FE/BE 环境中搜索表单的加载时间长

Question

我向您寻求有关 ACCESS FE/BE 应用程序的帮助。

我使用 VBA 已经有一段时间了（虽然只在 ACCESS 上使用了大约一年）但这是我真正需要在远程服务器上设置后端的第一个项目，并且我正在努力解决似乎是连接问题（我不是 VBA Dev）。我肯定做错了，所以请随时将我重定向到一个很好的教程，如果是这样的话，它可以帮助我解决问题。

所以，我的应用程序基本上是一个存储数据库，我们处理一个文件，通过 FE 将它与所有相关信息一起添加到 BE，用户可以查找诸如客户端 ID 或名称之类的内容来获取列表所有相关文件并查看它们的存储位置。

一切都在本地运行得非常好，并且对于一个用户在远程服务器上几乎是全面可用的，但是对于多个用户来说事情就变得复杂了。我认为数据库似乎需要完全加载到 RAM 中才能对其内容进行搜索，并且每当有人修改记录时，一些标志会告诉 Access 在新搜索中重新下载数据库以使所有内容都新鲜，这花费的时间太长了（每次大约 30 秒）。我猜一切都按预期工作，但我很难找到一种拥有多用户应用程序的好方法。我无法想象它应该如何工作，所以我想我做事的方式是错误的（或者它是服务器，它主要是整个公司的存储服务器，不是为了流量目的而设计的，但我不知道）。

我已将问题固定到此，这是有人使用搜索表单时调用的代码的一部分：

Set searchRST = dbs.OpenRecordset(SQLQuery, dbOpenSnapshot)

        If searchRST.RecordCount <> 0 Then
            If searchRST.EOF = False Then
                searchRST.MoveNext
            End If
            searchRST.MoveFirst
        End If

        Select Case searchRST.RecordCount
            Case 0
                .Controls("search_Results").Visible = False
                .Controls("Button_Load").Visible = False

                MsgBox ("No record found.")

            Case 1
                fileRST.FindFirst ("[ID] = " & searchRST![ID])
                Forms(const_File).Bookmark = fileRST.Bookmark
                .Controls("search_Results").Visible = False
                .Controls("Button_Load").Visible = False
                Call launchFileMode(modeVal)

            Case Is > 1
                searchRST.MoveLast
                "Others checks are made before displaying results in a subform control

基本上，当您输入搜索条件并单击一个按钮时，它会根据提供的 SQLQuery 字符串过滤数据库，遍历整个过滤后的记录集以便随后加载它，或者显示一条消息“Nothing found " 如果过滤记录集的 RecordCount 为 0，如果为 1 则显示唯一可用的文件（通过将 File 窗体当前加载的记录集的书签设置为过滤记录集的书签），或者在 a 中显示过滤记录集如果大于 1，则子表单，以便用户可以 select 要访问的文件。

SQLQuery 是一个根据不同搜索条件以编程方式创建的字符串（它旨在处理多条件搜索，但现在不使用），它给出如下内容：

SQLQuery = "SELECT * FROM [DB] WHERE [CLIENT ID] LIKE '0123456';"

加载时间不在同一点，具体取决于 RecordCount :

如果为 0，第 Set searchRST = dbs.OpenRecordset(SQLQuery, dbOpenSnapshot) 行将收取费用；
如果是 1，第 searchRST.MoveNext 行将收取费用；
如果它 > 1，行 searchRST.MoveLast（用于加载包含已过滤记录集的所有记录的子表单，以便您可以立即在其中向下滚动）将收取费用。

那是我迷路了。为什么不管记录集有多大，获取加载时间的不是同一行？如果实际上是检索数据的操作有问题，那么在每种情况下都应该是 dbs.OpenRecordset 行导致问题，不是吗？

我做事的方式可能是有史以来最糟糕的，因此非常感谢任何对此或处理这些搜索的任何其他方式的建议！

随时询问任何可能有帮助的详细信息。

（很抱歉，如果它不是 crystal 清楚，我正在争分夺秒地工作 post 从工作中我可以访问 accdb 文件）

Answer 1

如果只有一条记录，那为什么要先查找呢？如果查询与您发布的内容相似，那么在大多数情况下，这样的 ID 搜索可能只会 return 一条记录，而且应该很快。所以最重要的是标准限制了提取的记录数量。假设使用了某种类型的 "key"，那么正如在绝大多数情况下所指出的那样，您很可能只会 grab/return/pull 来自服务器的一条记录。您还需要 100% 确保您拥有持久连接（绑定表单对指向后端的链接 table 保持打开状态。

还假定您的应用程序是拆分的，并且每个工作站都有一份 FE。

它还假设后端服务器上的共享文件夹在您的本地网络上，而不是通过互联网的某种远程 "VPN" 类型的连接，后者通常比您的典型连接慢大约 100 倍办公网络。您可以在此处了解 LAN（局域网）与 WAN（广域网）之间的速度差异：

http://www.kallal.ca//Wan/Wans.html

如果您在 LAN 中工作，那么我不明白为什么性能很慢，或任何类型的问题（如果应用程序在一个用户下运行速度很快，但在两个用户下运行速度很慢，那么 10 次中有 9 次，持久连接技巧将解决此问题）。

所以基本假设是：您的应用程序已拆分。每个工作站都有一份前端副本。你有一个持久的连接。您在标准办公室 LAN 上工作，而不是某种 WAN（或 VPN）。

在 ACCESS FE/BE 环境中搜索表单的加载时间长

Long loading time on a search form in an ACCESS FE/BE environment

ms-access

ms-access-2013