访问，如果 *any* 模块上存在 *any* 错误，则报告公式上的 #Name 错误

Posted 2023-05-06

【中文标题】访问，如果 *any* 模块上存在 *any* 错误，则报告公式上的 #Name 错误

【英文标题】：Access, #Name error on report formula if there is *any* error on *any* module

【发布时间】：2021-06-16 10:29:31

【问题描述】：

我在 Access 2016 上尝试过，但我很确定自第一个版本以来一直如此。 让我们在报表字段中使用一个公式，在本例中为 Mid("abc",2)：

当我显示报告时，结果是正确的：

现在，如果出于任何原因我在 VBA 模块中出现语法错误（我不能排除其他类别的问题会导致相同的结果），与我在公式中使用的函数无关，公式进入错误状态，显示“#Name？”错误信息。

结果如下：

这很可怕，因为这意味着已经验证和使用的报告总是会显示错误并省略信息，因为不相关的模块中存在错误。 由于模块中的错误，所有报告公式都可能被破坏；在具有很多字段的复杂报告中，这可能会被忽视，直到客户意识到“#Name？”而不是关键信息。写好了。

我想阻止这种情况。是否可以在公式损坏的情况下引发异常，而不仅仅是显示#Name？ 是否有其他可能性可以达到这种可靠性水平？

【问题讨论】：

显而易见的答案是确保您的所有代码编译时没有语法错误！！

^是的。将该编译按钮添加到 VBE 工具栏。 -- 这真的是生产数据库的问题吗？客户应该得到一个编译好的.accde，如果出现语法错误，您将无法成功创建。

【参考方案1】：

不，没有，至少没有。

实际上只有一种方法可以避免这种情况：确保您的代码可以编译。如果您的代码无法编译，则没有任何功能可以信任。由于 VBA 允许覆盖函数，这是一件好事，因为您可能在该部分的某处声明了一个名为 Mid 的函数，该函数无法编译并且可能希望代码使用它。不编译等于“不知道发生了什么，没有什么是可信的”。

对于简单的项目，解决方法是在每次更改后混搭编译按钮（调试 -> 编译），并且永远不接受编译失败。

对于更复杂的项目，您可以将代码组织在不同的文件中并引用它们（请参阅this answer），如果一个文件编译失败，那只会影响引用该文件中任何内容的代码（确保重命名每个文件的VB项目，以避免名称冲突）。对于某些项目，使用它来将数据、表单和报告以及模块都保存在单独的文件中是明智的。