查询使 MS Access 崩溃
任务: 我正在将数据库从 MS Access 迁移到 Maximizer。为了做到这一点,我必须在 MS ACCESS 中获取 64 个表并将它们合并为一个。输出必须采用 TAB 或 CSV 文件的形式。然后将其导入 Maximizer。
问题: Access 无法执行看起来如此复杂的查询,因为每次运行查询时它都会崩溃。
替代方案: 我考虑了几种替代方案,并想做其中最耗时的一种,同时也利用任何机会学习新东西。
- 将每个表导出到 CSV 并导入到 SQLight,然后使用它进行查询以执行与 ACCESS 无法执行的操作相同的操作(合并 64 个表)。
- 将每个表导出为 CSV,并编写一个脚本来访问每个表并将 CSV 合并为一个 CSV。
- 以某种方式连接到 MS ACCESS DB (API),并编写一个脚本来从每个表中提取数据并将它们合并到 CSV 文件中。
问题: 你有什么建议吗?
澄清:
- 我正在合并表格,而不是连接表格。每个表都有不同的结构和不同的数据。它是一个标准化的 CRM 数据库。公司 -> 联系人 -> 详细信息 = ~ 60 个详细信息表。
- 由于数据库迁移后 Access 数据库将被破坏,因此我希望在 Access 上花费尽可能少的时间。
THE TASK:
I am in the process of migrating a DB from MS Access to Maximizer. In order to do this I must take 64 tables in MS ACCESS and merge them into one. The output must be in the form of a TAB or CSV file. Which will then be imported into Maximizer.
THE PROBLEM:
Access is unable to perform a query that is so complex it seems, as it crashes any time I run the query.
ALTERNATIVES:
I have thought about a few alternatives, and would like to do the least time-consuming one, out of these, while also taking advantage of any opportunities to learn something new.
- Export each table into CSVs and import into SQLight and then make a query with it to do the same as what ACCESS fails to do (merge 64 tables).
- Export each table into CSVs and write a script to access each one and merge the CSVs into a single CSV.
- Somehow connect to the MS ACCESS DB (API), and write a script to pull data from each table and merge them into a CSV file.
QUESTION:
What do you recommend?
CLARIFICATIONS:
- I am merging tables, not concatenating. Each table has a different structure and different data. It is a normalized CRM database. Companies->contacts->details = ~ 60 tables of details.
- As the Access db will be scuttled after the db is migrated, I want to spend as little time in Access as possible.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我同意 FrusteratedWithFormsDesigner 的观点。 #2 似乎是最简单的方法。
如果您决定走这条路,这里有一些经过测试的代码(需要 pyodbc):
I agree with FrustratedWithFormsDesigner. #2 seems the simplest method.
Here is some tested code if you decide to go that route (requires pyodbc):
既然要合并 64 个表,我们可以假设这些表都具有相同的结构吗?
如果是这样,请创建一个具有匹配结构的新空表,然后将这 64 个表中每个表的行附加到新的合并主表中。然后将合并主表导出为单个 CSV 文件。
合并操作不必是单个复杂查询。
您可以使用 VBA 代码构建 INSERT 语句 64 次,每次使用不同的 FROM 表。并使用 CurrentDb.Execute 执行每个语句
Since you want to merge 64 tables, may we assume those tables all have the same structure?
If so, create a new empty table with matching structure, then append the rows from each of those 64 tables into the new merge master table. Then export the merge master table as a single CSV file.
The merge operation should not have to be a single complex query.
You can build the INSERT statement 64 times with VBA code, with a different FROM table each time. And execute each statement with CurrentDb.Execute
如果合并相当简单明了,并且不需要 RDBMS 的强大功能,我会推荐#2。如果合并更复杂,并且您需要编写一些实际查询来正确合并数据,我会选择#1。
I would recommend #2 if the merge is fairly simple and straightforward, and doesn't need the power of an RDBMS. I'd go with #1 if the merge is more complex and you will need to write some actual queries to get the data merged properly.
我什至不清楚你想做什么。我假设您的问题是 Jet/ACE 无法处理具有那么多 SELECT 语句的 UNION 。
如果您有 64 个结构相同的表,并且希望它们位于单个 CSV 中,我会在 Access 中创建一个临时表,依次附加每个表,然后从临时表导出到 CSV。这是一个简单的解决方案,而且速度也不应该很慢。唯一可能的问题可能是是否存在重复,但如果存在,您可以从 SELECT DISTINCT 保存的 QueryDef 导出。
顺便说一句,我很惊讶 Maximizer 仍然存在。我有一个客户曾经使用它,并且数据库结构非常不规范,就像所有其他销售软件(如 ACT)一样。
I'm not even clear on what you're trying to do. I assume your problem is that Jet/ACE can't handle a UNION with that many SELECT statements.
If you have 64 identically-structured tables and you want them in a single CSV, I'd create a temp table in Access, append each table in turn, then export from the temp table to CSV. This is a simple solution and shouldn't be slow, either. The only possible issue might be if there are dupes, but if there are, you can export from a SELECT DISTINCT saved QueryDef.
Tangentially, I'm surprised Maximizer still exists. I had a client who used to use it, and the db structure was terribly unnormalized, just like all the other sales software like ACT.