我正在开发一个设备管理系统，前端使用 MS Access .mdb 文件，后端使用 SQL Server 2008。如果需要，我可以将前端转换为 MS Access 2010 文件。
我创建了一个日历表单，用户可以在其中查看哪些设备已预订、注销或过期。它看起来像这样：
我使用 42 个子表单制作了这个，不幸的是速度很慢。对于上面显示的数据，加载只需要大约 5 秒，但是一旦我使用真实数据，它就开始真正陷入令人无法接受的困境。我尝试通过将子表单的源对象保留为空白直到它们显示，并且直到此时才加载记录源，从而提高效率。这足以使上面的示例运行得相当快，但对于实际数据来说仍然不够。
所以我想做的是，要么找到一种方法在仍然使用子窗体的情况下提高效率，找到另一个可以代替子窗体的控件，要么用列表框切换子窗体，但仍然能够格式化颜色的行。我知道这对于列表框来说是不可能的，但我是一名程序员，如果不会浪费太多时间，我愿意尝试对列表框进行子类化来执行此操作。不幸的是，我从未做过任何 vba 子类化，因此需要向我指出一些好的资源才能这样做。
设置每天子表单的记录源的代码如下：
f("sub" & X & Y).Form.RecordSource = "SELECT * " & _
"FROM QRY_Calendar " & _
"WHERE CDate(StartDate) <= #" & curDate & "# " & _
"AND ((EndDate IS NULL OR CDate(EndDate) >= #" & curDate & "#)" & _
IIf(CDate(curDate) <= Date, " OR ((Date_In IS NULL OR CDate(Date_In) >= #" & curDate & "#) AND Date_Out IS NOT NULL)", "") & ") " & _
"ORDER BY IIF(Date_Out Is Not Null And (Date_In Is Null Or CDate2(Date_In)>=#" & curDate & "#) And CDate2(EndDate)<#" & curDate & "#,0,iif(CDate2(Date_Out)<=#" & curDate & "# And (Date_In Is Null Or CDate2(Date_In)>=#" & curDate & "#),1,2)), ID"
QRY_Calendar 看起来像这样：
SELECT B.ID, Person, Initials, ProjectNum & '-' & ProjectYear & '-' & Format(TaskNum,'000') AS Project, Sign_Out_Code, Value AS Type, StartDate, EndDate, Date_Out, Date_In
FROM (((TBL_Booking AS B INNER JOIN TBL_Person AS P ON B.PersonID = P.ID) INNER JOIN LKUP_List AS T ON B.EquipTypeID = T.ID) LEFT JOIN TBL_Usage AS U ON B.ID = U.BookingID) LEFT JOIN TBL_Equipment AS E ON U.Equipment_ID = E.ID;
表TBL_Booking中的StartDate和EndDate是预订的开始和结束，表TBL_Usage中的Date_Out和Date_In是签出的开始和结束。 每次注销都通过外键 BookingID 链接到预订。如果 Date_In 为 NULL，则表示设备当前已注销。
LKUP_List 是一个名字很糟糕的表，在我几年前开始工作之前，我从来没有费心去改变。它包含设备类型的列表（除其他外）。预订针对设备类型而不是特定项目，当用户注销其设备时，会在 TBL_Usage 中创建一条链接到特定设备的记录。
如果有人对我应该朝哪个方向以及我可以在哪里寻求指导有想法，我将不胜感激。
首先，Access 表单上 42 个子表单的加载速度非常快，事实上我已经这样做很多年了，42 个子表单的加载时间实际上是瞬时的。
因此，这表明读者可以忽略这里的一些评论，这些评论表明，与具有近直接能力的 Windows 高性能桌面应用程序相比，基于脚本或基于文本的解释系统（例如 HTML）在某种类型的浏览器渲染系统中运行速度会更快直接写入视频显卡。
请记住，如果您了解 Windows 桌面应用程序几乎可以直接写入显卡的简单和基本知识，那么很少有人会尝试进行比较，并且如果我们要进行比较，则建议 HTML 呈现的系统真正有希望在速度方面进行比较这里有两种不同的架构。
因此，这里真正的问题是日历的运行速度有多快，42 个子表单会成为问题吗？
答案很简单，42 个子表单不是问题，而且速度很快！
我的以下 Access 日历几乎立即呈现。
我的上述 Access 日历即使在生产环境中也已使用多年。即使日历每天都有更多无法显示在屏幕上的数据，它的加载时间也是即时的。其中很多正在运行，其中桌面（客户端）通过标准互联网连接到 SQLServer 后端，连接到网站上运行的 SQLServer 托管版本。即使在这种带宽更有限的情况下，日历的加载时间和响应也几乎是即时的。因此，无论我是否使用 accDB（基于文件）后端、使用 SQLServer 作为后端，性能都没有问题，更令人惊奇的是，正如所指出的，该表单与我的许多客户通过常规互联网连接运行此 Access 日历配合得很好。其后端是在托管网站上运行的 SQLServer。我什至有一个与 SharePoint（列表）后端一起运行的版本，并且它再次运行时没有问题和明显的延迟。
上述设计有 42 个子表单，并且如无数据所述，子表单绝对接近即时加载。声明这一点很重要，因此我提供了一些现实世界和事实证据来贬低那些显然不掌握和理解基本计算机体系结构的人在此发表的其他评论。因此，这些人会认为 42 个子表单的加载在某种程度上是一个降低软件速度的问题，而事实上我可以轻松地证明事实并非如此。因此，这里其他人的见证和证词可以被证明是没有根据的，因此这种观点是基于对我们行业中计算机的基本操作如何工作缺乏了解。 HTML 无法与此处的此类设置进行比较。
说到基于 Web，Access 允许进行 Web 发布，那么我将发布以下在 Access 中内置并在 Web 浏览器中运行的日历的视频。这个基于浏览器的日历仅使用 Access 构建，没有任何第三方工具。
http://www.youtube.com/watch?v=AU4mH0jPntI
上面视频的结果显示了此日历应用程序的基于 Web 的非常流畅且即时响应的版本。
现在我应该指出，在上面基于 Web 的示例中，我没有使用 42 个子表单，因为在 Web 浏览器中，每个表单都是一个单独的框架，并导致重新呈现从服务器发送的表单。这意味着对于基于 Access Web 的基于 42 个子表单的设计是不可能的。您将在渲染方面遭受巨大的性能损失（即使自 XMAL 表单按需加载以来没有数据以节省时间，但在这种情况下，此设置会受到影响）。
然而，正如视频所示，基于 Web 的解决方案（也适用于基于客户端的解决方案）是填写一个表格，在其中将文本框绑定到该表格。因此，如上述视频中所指出和所示，具有一个记录显示表明这样的结果意味着接近瞬时响应，并且甚至在网络浏览器中也如此。
我强调基于 WEB 的应用程序，因为该视频仅使用 Access 构建，没有使用其他工具。
现在回到性能问题和基于客户端的应用程序。当然，我们现在知道加载 42 个子表单不是问题。
当然，问题是运行 42 个带有各种表达式的独立 SQL 查询来将数据拉入这些子表单，这就是瓶颈和性能缓慢的地方。因此，如果我们使用 42 个文本框，甚至 42 个列表框，这个性能问题不会改变。
所以问题是尝试执行 42 个单独的 SQL 查询。请记住，每个 SQL 查询都需要时间来解析、检查语法，然后构建查询计划等。事实上，在某个给定查询的数据甚至开始流动之前，必须发生相当多的操作。事实上，我发现一次查询可能会消耗大约 10,000 行数据流的带宽。
根据以上信息，我的设计中这42个子表单之所以能够瞬时加载并执行，是因为我只执行一个查询来返回整个月的数据。换句话说，我使用显示的开始日期和结束日期执行查询。然后，我运行 VBA 代码将生成的记录集中的数据处理到子表单 1 到 42 中。因此，VBA 代码将生成的记录集数据填充到 42 个子表单中。这是这里的关键概念和建议，以确保高性能计算并且不会降低速度。
所以总结和结论是：
性能瓶颈不在于使用 42 个子表单，而在于拥有 42 个记录集和 42 个查询，并且可能需要计算 42 次额外的代码和表达式。消除 42 次查询和 42 次并且必须重新执行这样的 SQL 语句，这个瓶颈几乎就会消失。
我敢说，使用 42 个列表框，甚至只是 42 个文本框并继续执行 42 条这样的 SQL 语句不会产生任何值得的性能改进。