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

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

我现在使用VBA已经有一段时间了（虽然只在ACCESS上使用了一年左右），但这是我实际需要在远程服务器上设置后端的第一个项目，我正在努力解决连接问题（我不是VBA开发人员）。我肯定做错了，所以请随意给我介绍一个好的教程，如果是这样的话，可以帮助我把事情弄清楚

因此，我的应用程序基本上是一个存储数据库，我们处理一个文件，通过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

加载时间不在同一点，具体取决于记录计数：

• 如果为0，则行

  Set searchRST=dbs.OpenRecordset（SQLQuery，dbOpenSnapshot）

  将收取费用
• 如果是1，则行

  searchRST.MoveNext

  将收取费用
• 如果大于1，则行

  searchRST.MoveLast

  （用于加载包含已筛选记录集的所有记录的子窗体，以便您可以毫不延迟地向下滚动）将收取费用

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

我可能做的事情有史以来最糟糕的方式，所以任何关于这个或任何其他方式处理这些搜索的建议将不胜感激

请随意询问任何可能有帮助的细节

---

（很抱歉，如果它不是非常清晰，我正在分秒必争地把它从我可以访问accdb文件的工作中发布）

如果只有一条记录，为什么要先查找？如果查询与您发布的内容类似，那么在大多数情况下，这样的ID搜索可能只返回一条记录，而且应该很快。因此，最重要的是，标准限制了提取的记录数量。假设使用了某种类型的“密钥”，那么在绝大多数情况下，您可能只会从服务器抓取/返回/拉取一条记录。您还需要100%确保具有持久连接（绑定表单对指向后端的链接表保持打开状态）

还假定您的应用程序被拆分，并且每个工作站都有FE的副本

它还假设后端服务器上的共享文件夹位于您的本地网络上，而不是internet上某种远程“VPN”类型的连接，这种连接通常比您的典型办公网络慢100倍。您可以了解LAN（局域网）与WAN（广域网）之间的速度差在这里：

如果您是在局域网上工作的，那么我不明白为什么性能会很慢，或者任何类型的问题（如果it应用程序在一个用户上运行得很快，但在两个用户上运行得很慢，那么10次中有9次，持久连接技巧可以解决这个问题）

因此，基本假设是： 您的应用程序被拆分。 每个工作站都有一个前端的副本。 你有一个持久的连接。

---

您使用的是标准的办公局域网，而不是某种WAN（或VPN）。

我使用RecordsetClone和Bookmark进行搜索操作-没有recordset对象变量。例如：

Me.RecordsetClone.FindFirst“LabNum=”&Me.OpenArgs&“”“Me.Bookmark=Me.RecordsetClone.Bookmark

谢谢！我明天会尝试。（虽然我想我几个月前就已经尝试过设置RecordsetClone了（我现在回到这个问题上），但它在搜索中不起作用，但可能我使用的方式不同。我会尝试一下。）碰巧我至少两周内都无法处理它，所以非常感谢6月7日和Albert D.Kallal提供的线索，我会尽快尝试您的方法，看看是否有任何改进，但现在我将Albert answer标记为已接受，因为这很可能是服务器类型相关的问题。我猜这是WAN？肯定不是LAN，因为服务器至少可以被所有中心站点访问（这是全国的一半）。我会做一些速度测试，看看服务器是否有问题。我会检查今天下午我是否也打开了一个持久连接。好吧，如果广域网使用互联网，那么你会慢很多倍。阅读我的那篇文章。一个典型的高速互联网说，15mbps，你的办公室局域网通常是1000。你可以做三年级的数学这里。所以是的，一定要询问连接速度，但是你典型的T1线高速互联网速度是10倍，或者说是50倍。（所以3秒变成150秒（2.5分钟）所以说如果4分钟太慢，那么花更多的钱来加倍速度意味着你2-3秒的查询或操作现在从4分钟下降到2分钟。考虑后端的SQL Server。是的，我今天读了这篇文章（顺便说一下）。不幸的是我不能设置一个。

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