如何提取 Access (.mdb) 数据库的架构?
我正在尝试提取 .mdb 数据库的架构,以便我可以在其他地方重新创建数据库。
我怎样才能完成这样的事情呢?
I am trying to extract the schema of an .mdb database, so that I can recreate the database elsewhere.
How can I pull off something like this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(10)
查看 docmd.TransferDatabase 命令。 对于需要复制数据结构的构建集成来说,这可能是您的最佳选择
Check out the docmd.TransferDatabase command. It is probably your best bet for build integration that needs to replicate the data structure
比较他们
http://home.gci.net/~mike-noel/ CompareEM-LITE/CompareEM.htm
将愉快地生成重新创建 MDB 所需的 VBA 代码。 或者创建两个 MDB 之间差异的代码,以便您可以对现有的 BE MDB 进行版本升级。 这有点奇怪但有效。 请注意,它不支持新的 ACE (Access2007) ACCDB 等格式。
我用它所有的时间。
(OneDayWhen 的编辑有三分之一正确,三分之二错误。)
Compare'Em
http://home.gci.net/~mike-noel/CompareEM-LITE/CompareEM.htm
will happily generate the VBA code need to recreate an MDB. Or the code to create the differences between two MDBs so you can do a version upgrade of the already existing BE MDB. It's a bit quirky but works. Note it does not support the new ACE (Access2007) ACCDB etc formats.
I use it all the time.
(OneDayWhen's edit was one third right and two thirds wrong.)
在 Access 中执行 DDL 脚本/查询很困难。 这是可以完成的,但您最好只创建数据库的副本 - 删除所有数据并压缩它。 然后使用该副本在其他地方重新创建数据库。
It's hard to do DDL scripts / queries in Access. It can be done but you'd be better off just creating a copy of the database - deleting all the data and compacting it. Then use a copy of this for recreating the database elsewhere.
非常有帮助的帖子!
我修改了脚本来生成 SQL Server 的数据定义语言。 我认为它可能对某人有用,所以我分享它。 我遇到的一个问题是 VBS 脚本提取表中的所有字段作为索引。 我还不确定如何解决这个问题,所以我只提取第一个字段。 这适用于大多数主键。 最后,并不是所有的数据类型都得到了证明,但我想我已经得到了大部分。
Very helpful post!
I have revised the script to generate the data definition language for SQL server. I thought it might be useful to someone, so I'm sharing it. The one problem I ran into is that the VBS script extracts all fields in the table for indexes. I'm not sure how to solve this just yet, so I extract only the first field. This will work for most primary keys. Finally, not all of the data types are proven, but I think I got most of them.
罗兰上面的答案(由托比亚斯编辑)对我有用,但有一些变化。 首先我解决了查找主键中所有字段的问题; 那么索引sql代码写入文件的位置是错误的:
选项比较数据库
Roland's answer above (edited by Tobias) worked for me but with a couple of changes. Firstly I solved the issue of finding all fields in the primary key; then the writing to file of the index sql code was in the wrong place:
Option Compare Database
用VBA 可以做一些事情。 例如,这里是为具有本地表的数据库创建脚本的开始。
It is possible to do a little with VBA. For example, here is a start on creating script for a database with local tables.
现在这是一个古老的问题,但不幸的是长期存在:(
我认为这段代码可能对其寻求解决方案的其他人有用。它设计为通过 cscript 从命令行运行,因此无需将代码导入到您的 Access 项目中。类似于(并受到启发)来自 Oliver 的代码 如何在 Access 开发中使用版本控制。
如果您还想导出查询定义,这个问题应该有帮助。有点不同因为您通常不会使用普通的 DDL
CREATE VIEW foo AS ...
语法创建 querydef,事实上我不确定您可以(?)但是这是我编写的一小段脚本将查询备份到单独的 .sql 文件(这是用于备份所有前端数据库代码的较大脚本的一部分,请参阅奥利弗的答案 这个问题)。
It's an ancient question now, but unfortunately perennial :(
I thought this code may be of use to others looking for solutions. It's designed to be run from the command line via cscript, so no need to import code into your Access project. Similar to (and inspired by) the code from Oliver in How do you use version control with Access development.
If you are looking to export query definitions as well, this question should help. It's a little different because you don't usually create querydefs with plain DDL
CREATE VIEW foo AS ...
syntax, in fact I'm not sure you can (?)But here's a little piece of a script I wrote for backing up queries to separate .sql files (which is part of a larger script for backing up all front-end db code, see Oliver's answer for this question).
以下 C# 概述了如何从 .mdb 文件获取架构。
获取数据库连接:
获取每个表的名称:
获取每个表的字段:
3
、11
和27
在哪里来自? 我通过使用调试器检查DataRow.ItemArray
找到了它们,有人知道“正确”的方法吗?这是 ProVega 在此答案的评论中提到的屏幕截图:
The following C# outlines how to obtain the schema from a .mdb file.
Obtain a connection to the database:
Get the name of each table:
Get the fields for each table:
Where do the
3
,11
and27
come from? I found them by inspectingDataRow.ItemArray
with a debugger, does anyone know the 'correct' way?Here is the screenshot ProVega alludes to in the comments of this answer:
如果您愿意使用纯 Access SQL 之外的其他内容,则可以保留 ADOX 对象的集合并使用它们来重新创建表结构。
示例(在 Python 中,当前不重新创建关系和索引,因为我正在处理的项目不需要它):
类似的反向函数使用第二个连接字符串重建数据库。
If you're happy to use something other than pure Access SQL, you could persist a collection of ADOX objects and use those to recreate the table structure.
Example (in Python, doesn't currently recreate relationships and indexes as it wasn't needed for the project I was working on):
A similar reverse function reconstructs the database using the second connection string.
您可以使用 ACE/Jet OLE DB 提供程序和 ADO Connection 对象的 OpenSchema 方法来获取作为 Recordset 的架构信息(这可能比 Collection 更好,因为它可以进行过滤、排序等)。
基本方法是使用 adSchemaTables 获取基表(不是 VIEW),然后使用每个 TABLE_NAME 获取 ORDINAL_POSITION、!DATA_TYPE、!IS_NULLABLE、!COLUMN_HASDEFAULT、!COLUMN_DEFAULT、!CHARACTER_MAXIMUM_LENGTH、!NUMERIC_PRECISION、!NUMERIC_SCALE 的 adSchemaColumns。
adSchemaPrimaryKeys 很简单。 adSchemaIndexes 是您可以找到 UNIQUE 约束的地方,不确定这些约束是否可以与唯一索引区分开,还有要插入 adSchemaForeignKeys 行集的外键名称,例如(伪代码):
-- 注意 Jet 3.51 允许 FK 的陷阱基于无名 PK (!!)
验证规则和 CHECK 约束的名称可以在 adSchemaTableConstraints 行集中找到,使用 OpenSchema 调用中的表名称,然后使用调用 adSchemaCheckConstraints 行集中的名称,过滤 CONSTRAINT_TYPE = ' CHECK' (陷阱是名为 'ValidationRule' + Chr$(0) 的约束,因此最好转义名称中的空字符)。 请记住,ACE/Jet 验证规则可以是行级或表级(CHECK 约束始终是表级),因此您可能需要在过滤器中使用表名:对于 adSchemaTableConstraints 是 [].[].ValidationRule将是 adSchemaCheckConstraints 中的 [].ValidationRule。 另一个问题(疑似错误)是字段的宽度为 255 个字符,因此任何超过 255 个字符的验证规则/CHECK 约束定义都将具有 NULL 值。
adSchemaViews 用于基于非参数化 SELECT SQL DML 的访问查询对象,非常简单; 您可以使用 adSchemaColumns 中的 VIEW 名称来获取列详细信息。
PROCEDURES 位于 adSchemaProcedures 中,是所有其他类型的 Access Query 对象,包括参数化 SELECT DML; 对于后者,我更喜欢用 PROCEDURE_DEFINITION 中的 CREATE PROCEDURE PROCEDURE_NAME 替换 PARAMETERS 语法。 不要费心查看 adSchemaProcedureParameters,您将找不到任何内容:可以通过使用 ADOX Catalog 对象返回 ADO 命令来枚举参数,例如(伪代码):
然后枚举 .Name 的 Comm.Parameters 集合, .Type 表示 DATA_TYPE,(.Attributes 和 adParamNullable)表示 IS_NULLABLE,.Value 表示 COLUMN_HASDEFAULT 和 COLUMN_DEFAULT,.Size、.Precision、.NumericScale。
对于 ACE/Jet 特定的属性(例如 Unicode 压缩),您需要使用另一种对象。 例如,可以使用 ADO Catalog 对象找到 Access-speak 中的长整型自动编号,例如(伪代码):
祝你好运:)
You can use the ACE/Jet OLE DB Provider and an ADO Connection object's OpenSchema method to get schema information as a Recordset (which is arguable better than a Collection because it can be filtered, sorted, etc).
The basic methodology is to use adSchemaTables to get the base tables (not VIEWs), then use each TABLE_NAME to fetch adSchemaColumns for ORDINAL_POSITION, !DATA_TYPE, !IS_NULLABLE, !COLUMN_HASDEFAULT, !COLUMN_DEFAULT, !CHARACTER_MAXIMUM_LENGTH, !NUMERIC_PRECISION,!NUMERIC_SCALE.
adSchemaPrimaryKeys is straightforward. adSchemaIndexes is where you will find UNIQUE constraints, not sure wether these can be distinguished from unique indexes, also the names of FOREIGN KEYs to plug into the adSchemaForeignKeys rowset e.g. (pseudo code):
-- watch for the gotcha that Jet 3.51 allows a FK based on a nameless PK (!!)
Names of Validation Rules and CHECK constraints can be found in the adSchemaTableConstraints rowset, using the table name in the OpenSchema call, then use the name in the call to the adSchemaCheckConstraints rowset, filter for CONSTRAINT_TYPE = 'CHECK' (a gotcha is a constraint named 'ValidationRule' + Chr$(0), so best to escape the null characters form the name). Remember that ACE/Jet Validation rules can be either row-level or table-level (CHECK constraints are always table-level), so you may need to use the table name in the filter: for adSchemaTableConstraints is [].[].ValidationRule will be [].ValidationRule in adSchemaCheckConstraints. Another gotcha (suspected bug) is that the Field is 255 characters wide, so any Validation Rule/CHECK constraint definition of more than 255 characters will have a NULL value.
adSchemaViews, for Access Query objects based on non-paramaterized SELECT SQL DML, is straightforward; you can use the VIEW name in adSchemaColumns to get the column details.
PROCEDURES are in adSchemaProcedures, being all other flavours of Access Query objects including parameterized SELECT DML; for the latter I prefer to replace the PARAMETERS syntax with CREATE PROCEDURE PROCEDURE_NAME in the PROCEDURE_DEFINITION. Don't boterh looking in the adSchemaProcedureParameters, you won't find anything: the parameters can be enumerated by using an ADOX Catalog object to return an ADO Command e.g. (pseudo code):
then enumerate the Comm.Parameters collection for the .Name, .Type for DATA_TYPE, (.Attributes And adParamNullable) for IS_NULLABLE, .Value for COLUMN_HASDEFAULT and COLUMN_DEFAULT, .Size, .Precision, .NumericScale.
For ACE/Jet-specific properties such as Unicode compression you need to use another kind of object. For example, a Long Integer Autonumber in Access-speak can be found using an ADO Catalog object e.g. (pseudo code):
Good luck :)