所谓的数据宏当然很像表触发器。它们可以而且应该工作,而无需启动或什至在计算机上运行 Access 的副本。
但是,如果数据宏使用“任何”VBA 函数,那么只有在您启动 Access 时这样的宏才会起作用。
因此,您必须删除 =CurrentUser() 的使用,因为这似乎是 VBA 函数。
因此,您开始使用 VBA 函数的瞬间,即您编写的那些表触发器、事件和代码将不起作用的瞬间。(即:除非从 Access 运行,否则不起作用)。因此,如果其他系统(FoxPro、Vb6 或其他系统)使用数据宏确实可以正常工作。只是在执行此操作时不能引入 VBA 代码。
虽然您“可以”从这些表触发器中调用或使用 VBA 代码,但强烈建议您不要这样做。
因此,如果您使用 Vb6 vb.net、FoxPro 等打开 Access 数据库,您可以更新数据,并且您拥有的过程宏代码将运行和执行。
但是,Vb6、FoxPro(您的 java)等没有使用 VBA 代码(Visual Basic For Applications),因此数据引擎无法使用。
如果您的表事件代码(数据宏)使用任何外部 VBA 代码,那么您只能使用 Access 作为更新此类表的方法,因为任何其他系统都没有可用的 VBA 库和代码。
事实上,您可以将 jet(现在称为 ACE)安装为 100% 单独安装。因此,对于您编写的程序表代码,Access 数据库引擎 (ACE) 不需要在目标计算机上安装 VBA。也不必安装 Access 的副本。
因此,如果您的数据宏引用或使用任何外部 VBA 函数,那么可以对表进行更新的唯一客户端将是 Access,因为没有其他接口可以提供解析 VBA 代码库和系统的“表达式服务” .
并且没有获取当前用户的数据宏功能。因此,实现这一点的唯一方法是在启动时使用一些代码将“当前用户”设置为表(比如 1 条记录)。然后数据宏可以从表中读取该 1 条记录以获取“当前用户”。当然,这种设置在多用户设置中不起作用,但对于本地文件,这可能是“kluge”类型的孤子。
这也意味着您的启动代码(VB6、Java 等)。您正在编写代码将不得不更新具有当前用户的 1 行的“用户”表 - 据我所知,您无法从数据宏中获取此信息。
但是,虽然当前用户在数据宏中不可用,但在标准非表宏中可用。
但是,数据(表)宏只有本地变量。如果数据宏可以调用用户宏,那么您可以这样做。
因此,您不能从数据宏调用或使用 VBA 代码——它们向 VBA 引入了外部依赖关系,除非加载 Access,否则该依赖关系不可用。
数据宏是独立的路由——即使更新发生在 Access 前端应用程序之外,它们也会运行。但是,在 Access 前端之外使用时,数据引擎不会加载或使用 VBA。