Access 和 VBA，什么是大型可扩展应用程序的最佳“架构”答案

【问题标题】：Access & VBA, what is best "architecture" for a large, scalable applicationAccess 和 VBA，什么是大型可扩展应用程序的最佳“架构”
【发布时间】：2016-07-20 01:01:25
【问题描述】：

我想知道混合 Access、SQL 和 VBA 的最佳方法是什么。因为我目前正在开发一个大型应用程序，该应用程序可能会在未来发展，我问自己是否做对了。

我选择在独立的 VBA 模块中“硬编码”我的大部分 SQL 查询，只给出条件值（SELECT/DELETE）或字段值（INSERT/UPDATE）作为参数。我首先发现这很方便，因为我所要做的就是在我的表单代码中进行过程调用，只需传递我的控件所需的值。

但问题是，如果我添加一个新字段，重命名我的表或重命名一个字段，我将不得不一个一个地重写与该表有关的所有查询......这很烦人

我想知道是否存在“标准架构”来方便地在 Access 中使用可扩展的应用程序？

我所说的可扩展性是指数据库本身和应用程序逻辑。

【问题讨论】：

如果您想要一个大型、可扩展的应用程序，我的建议是根本不要使用 Access 和 VBA。相反：使用 C# 和 SQL-Server。
感谢您的快速回答，我知道 Access 不是提供此类应用程序的最佳工具，但我别无选择，我正在接受培训并与 MS Access 合作。我不需要一个极其健壮的架构，只需要一种使代码更易于维护且对小更改不完全敏感的方法；-(
我直接同意 SQL Server 和不包含在其中的语言，例如 .net vb/C#。不过，您的问题似乎自相矛盾，您说您正在传递参数以执行操作，但如果您是传入参数，那么这些肯定是需要它的字段，而新字段需要检查/更改代码。如果您使用 ADO 连接，则可以打开 DB 模式以获取表和字段等的详细信息，因此您可以使用前缀字段执行此操作，例如 UP_Firstname，然后将允许您打开模式并获取以 UP_ 开头的字段名称可更新..
Access 比较麻烦，复制不错，就是有点笨重
“那么肯定这些是需要它的字段，而新字段需要检查/更改代码”，是的，这正是我遇到的问题！我会看看你给我的技巧是否能让我更轻松

标签： sql ms-access architecture vba

【解决方案1】：

...问题是如果我添加一个新字段，重命名我的表或重命名一个字段，我将不得不重写有关该字段的所有查询一张一张的表格

我建议您使用QueryDef 对象（已保存的查询），而不是将 SQL 语句文本保存在代码模块中。

然后，当您的查询引用了稍后更改的表或字段名称时，您不必手动确定哪些查询需要修改并一次编辑这些查询。你可以使用swapTblNamesInQueryDefs() 之类的东西。我是为表名写的，但它也适用于字段名。

如果您继续将 SQL 语句保留在代码模块中，您可以使用查找和替换执行类似的操作。然而，一个潜在的复杂情况是，单词替换不仅限于 SQL 语句文本。当目标词出现在您的 VBA 代码中的其他地方但您不希望替换这些出现时，这将是一个问题。当您的 SQL 在 QueryDef 对象中时，这不是问题。

添加新字段更具挑战性。您可以在 DisplayOnly 模式下使用swapTblNamesInQueryDefs() 来检查查询中包含已修改表名称的 SQL。但是，我没有看到任何可自动化的方式来确定应该修改哪些查询并进行所需的更改。

【讨论】：