访问 UI（控制源属性）与 VBA 性能答案

【问题标题】：Access UI (controlsource property) vs VBA Performance访问 UI（控制源属性）与 VBA 性能
【发布时间】：2015-01-11 11:45:11
【问题描述】：

使用 Access UI 并设置属性以向文本框（或其他控件）添加值与使用 VBA 执行相同操作时，性能（速度、使用的内存等）是否存在差异？对象变量是否正确使用？

例如，假设我想从列表框中选择一个项目并将所选记录中的值添加到 2 个文本框控件。我可以通过在列表框的AfterUpdate 事件过程中使用以下 VBA 代码来做到这一点：

Private Sub lstTest_AfterUpdate()
Dim lstA As Control

Set lstA = Me.lstTest

Me.txtTest1 = lstA.Column(0)
Me.txtTest2 = lstA.Column(1)

Set lstA = Nothing

End Sub

我还可以使用 MS Access UI 通过 txtTest1 和 txtTest2 控件中的“属性”窗口将 ControlSource 属性设置为以下，以达到相同的结果。

txtTest1 控制源：=[lstTest].[Column](0)

txtTest2 控制源：=[lstTest].[Column](1)

就性能而言，这两种方法有什么区别吗？任何有关这方面的文档将不胜感激。

【问题讨论】：

标签： performance vba ms-access

【解决方案1】：

存在“一点”差异，但实际上并不会影响应用程序性能的成败。

可以认为第一个示例更好，因为值被“填充”到其他控件中。问题当然是下次加载表单时，如果 txtTest1/2 未绑定，那么下次加载表单时，您可能必须运行一些代码来重新加载值。（所以这让第一个例子变得更糟）

因此，在您的第一种情况下，这些值将不会持续存在，并且在您下次加载表单（或导航到不同的记录）时，这些值将不会更新，因为您的第一个示例仅在更新后事件触发时更新值.更新事件后仅在您更改组合框时触发，而不是在一般表单加载或导航时触发。

所以问题可能不是性能问题，而只是您的第一个示例的问题将无法工作，也不会在下次加载表单时显示数据（当然，除非文本框绑定到底层列）。

由于代码需要在表单加载或记录导航发生时始终运行，因此您可能最好使用控制源方法，因为在这两种情况下您都可能希望这些值正确显示，因此在这两种情况下您都必须引用.column() 属性。

【讨论】：

这是有道理的，我主要是对这两种方法之间的任何细微差别感到好奇。我通常更喜欢尽可能使用 Access UI，在测试它时，似乎控制源方法可能更有效，但很难说。谢谢！
使用控制源方法的一个警告似乎是，如果您使用 INSERT SQL 字符串编辑记录，那么您必须使用 AfterUpdate 事件，否则它将不允许用户编辑数据。