Question

我使用pyodbc，通过Microsoft Jet，从Python程序访问Microsoft Access 2003数据库中的数据。

Microsoft Access数据库来自第三方;我只是在读数据。

我一直在成功提取我需要的数据，但最近我注意到了一些差异。

我把它归结为一个简单的查询，格式为：

SELECT field1 FROM table WHERE field1 = 601 AND field2 = 9067

我对字段名称和值进行了模糊处理，但实际上，它并没有比这更简单！当我在Access中运行查询时，它返回一条记录。

然后我在pyodbc上运行它，代码如下：

connection = pyodbc.connect(connectionString)
rows = connection.execute(queryString).fetchall()

（同样，它并没有比那更简单！）

queryString的值是从Access中的工作查询中剪切并粘贴的，但它返回 no 记录。我预计它会返回相同的记录。

当我更改查询以搜索field2，bingo的不同值时，它可以正常工作。这只是它拒绝的一些价值。

所以，请帮帮我。接下来我应该在哪里解释这种差异？如果我不相信琐碎的查询结果，我就没有机会参与这个项目了！

更新：它变得更简单！以下查询给出了不同的数字......

SELECT COUNT（*）FROM table

我认为它是否与某些形式的缓存和/或另一个偶尔会填充数据的应用程序进行不正确的事务管理有关。

Answer 1

你能给我们一个模糊的数据库来显示这个问题吗？我从来没有经历过这个。至少给出表定义 - 是浮点数还是十进制数？

Answer 2

这可能听起来很愚蠢。但...

是实际数据库和路径的路径吗？连接字符串（DSN）指向同一文件位置？

Answer 3

您是否遇到与其他ODBC工具相同的问题，例如Query Tool？您还可以在ODBC连接管理器中打开ODBC跟踪。我没有访问权限并且不知道是否会跟踪它的sql命令，但有时它可以帮助我解决ODBC问题。

Answer 4

字段是否已编入索引？如果是这样，可能其中一个索引已损坏，您需要压缩MDB文件。如果索引损坏，则可能导致重大问题。您可能会丢失现有关系（如果损坏的索引是PK），或者您可能丢失数据。因此，在执行此操作之前，您需要备份。如果有一个损坏的索引，我认为交互式Access紧凑操作会告诉你，但如果没有，你可以查找MSysCompactErrors表，它会告诉你在压缩过程中发生了什么错误。

这种情况很少发生，可以表明两件事之一：

糟糕的应用程序设计，包括过时的Jet版本（Service Pack 6之前的Jet 4非常容易受到影响，而这就是我遇到它的地方）。
不可靠的操作环境（网络/硬件/软件）。

当然，这个建议是一个真正的远景，但它肯定是导致不同结果的一个原因（最常见的是对腐败索引的ORDER BY，你最终会得到与另一个不同的记录数订购）。

Answer 5

问题在升级到Access 2007和从源下载数据库的新副本之间解决了。仍然不知道根本原因是什么，但怀疑某种形式的指数腐败。

Answer 6

我想问题可能是你没有提交查询。 PYODBC以autocommit = False开头，因此每个查询（如select，insert，update等）都将启动一个事务，以便您必须提交效果。在查询之后拨打connection.autocommit = True或致电cursor.execute("commit")，然后取消预订。

PyODBC和Microsoft Access：简单查询的结果不一致

6 个答案: