如何导出Access 2010数据宏

Question

我需要将Access数据宏从我的测试数据库传输到我的生产数据库.有谁知道怎么做？

我知道将表从一个accdb转移到另一个accdb也会传输数据宏,但在我的情况下这不是一个选项.我也知道我可以在生产accdb中手动重新创建它们,但这使我容易出错,并且需要将生产数据库关闭的时间比脚本传输方案要长.

如果我不得不这样做一次就不会那么大,但我需要在开发项目的过程中多次这样做.

我已经尝试将表导出到xml,但不包括数据宏.

请注意,我在这里询问Access 2010 数据宏,而不是常规的Access宏.

Answer 1

您可能想尝试一对未记录的VBA函数

出口:

SaveAsText acTableDataMacro, "TableName", "C:\PathToFile\DataMacro.xml"

要导入:

LoadFromText acTableDataMacro, "TableName", "C:\PathToFile\DataMacro.xml"

Answer 2

为了扩展Martijn Pieters'/ Lanik的答案(感谢Martijn和Lanik),我需要在28个不同的表上创建几乎相同的数据宏,每个表都有AfterInsert,AfterUpdate,AfterDelete和命名数据宏.所以,我使用了SaveAsText命令

SaveAsText acTableDataMacro,"TableName","C:\ PathToFile\DataMacro.xml"

创建一个模板,然后使用该模板通过一个小的vba代码创建28 xml文件,替换表名,主键等.我还创建了28个LoadFromText命令.然后,我可以使用LoadFromText命令一次加载所有宏,并使用可重复的过程.现在我已经完成了测试,我可以通过这种方式快速更新生产数据库,或者轻松地将相同的数据宏添加到其他表中.

所以其他人都知道,LoadFromText会覆盖任何以前的宏,这非常棒,因为我第一次尝试时没有正确的模板.

鉴于上述情况,下一步是让"updater"数据库应用程序使用DoCmd.TransferDatabase命令将带有函数/ sub的模块与所有LoadFromText命令一起传输到Data .accdb.它还应该传输一个宏来运行函数/ sub.我尝试使用我的更新程序然后执行宏来加载数据宏,但访问安全性阻止了这一点.所以,您可能需要让用户打开数据库并启用它,然后运行宏.如果我们可以直接编辑数据宏,那么这会更复杂,但确实提供了解决问题的解决方法.

Answer 3

我在这里没有很好的答案。

然而，过去我经常对表格的更改制作一个“日志”，然后在现场简单地使用它。

请注意，您可以剪切+粘贴宏代码。并且代码保存为 XML。

例如，更新后表触发器在 Access 中如下所示：

如果您剪切了上面的内容（ctrl-a，ctrl-cc），那么您可以将其粘贴到记事本中。事实上，您甚至可以在 Visual Studio 或任何 xml 编辑器中粘贴/打开它，您会看到以下内容：

因此您可以从这些宏中剪切+粘贴。

如前所述，因此过去我经常保留更改的“日志”。

因此，如果我在场外工作并修改了 2 个代码模块、4 个表单和 2 个报告，那么我就会有一些更改日志。我将在这张表中输入更改的对象。

当我到达现场时，我快速浏览了该工作表，我知道要导入 3-5 个对象，而这样的导入最多只需几分钟。

但是，使用表触发器和存储过程，您可以复制更多内容。

我会做以下两件事之一：

使用日志思想和

a) 取消发布开发版本并将其带到您的工作站点。然后导入新的表单、报告等。对于触发代码，您可以在两个应用程序之间剪切+粘贴。

b) 当您对触发器进行更改时，然后剪切并粘贴到记事本文档中并将它们放在目录中。在现场时，只需取出每个记事本，剪切+粘贴到生产中，然后将记事本项目移动或复制到“完成”文件夹中。

上述情况肯定不太理想。然后，在过去，我并不总是有代码来编写表更改的脚本，并且使用一个小日志表效果很好。

所以以前我经常只是写下某某表被修改了，我必须添加某某列。

因此，您可以选择是否要将宏代码作为 xml 剪切+粘贴到单独的小文档中，或者直接从开发中剪切+粘贴到生产中。

我确实认为，如果您在不同的位置工作，那么我认为最好取消发布开发版本，并将其随身携带（我假设您知道/意识到您可以制作 Web 应用程序的未发布副本） 。

因此，表单、代码模块、宏等可以相当容易地导入（您删除表单等，然后从未发布的副本导入）。

但是，对于表代码呢？您必须一次将未发布的副本剪切+粘贴到某个暂存区域，或者如上所述在应用程序之间剪切+粘贴。

另存为文本可能在这里起作用，但我还没有时间制定更好的解决方案。

编辑：顺便说一句，在上面我假设了一个 Web 服务数据库，但该建议仍然适用于非 Web Access 数据库。