PyODBC und Microsoft Access: Inkonsistente Ergebnisse von einfachen Abfrage

Question

Ich verwende pyodbc, über Microsoft Jet, um auf die Daten in einer Microsoft Access 2003-Datenbank von einem Python-Programm zuzugreifen.

Die Microsoft Access-Datenbank stammt von einem Drittanbieter; Ich lese nur die Daten.

Ich habe im Allgemeinen Erfolg bei der Extraktion der Daten, die ich brauche, aber ich habe kürzlich einige Diskrepanzen festgestellt.

Ich habe es gekocht auf eine einfache Abfrage nach unten, von der Form:

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

Ich habe die Feldnamen und Werte verschleiert aber wirklich, ist es nicht viel mehr trivial als das! Wenn ich die Abfrage in Access ausführe, gibt es einen Datensatz zurück.

Dann laufe ich es über Pyodbc, mit Code, der wie folgt aussieht:

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

(Wieder ist es nicht viel mehr trivial als das bekommt!)

Der Wert von querystring wird geschnitten -und-eingefügt von der Arbeitsabfrage in Access, aber es gibt keine Datensätze zurück. Ich habe erwartet, dass es den gleichen Rekord zurückgibt.

Wenn ich die Abfrage ändern, um nach einem anderen Wert für Feld2, Bingo zu suchen, funktioniert es. Es sind nur einige Werte, die es ablehnt.

Also, bitte helfen Sie mir aus. Wo soll ich als nächstes diese Diskrepanz erklären? Wenn ich den Ergebnissen trivialer Anfragen nicht trauen kann, habe ich bei diesem Projekt keine Chance!

Update: Es wird noch einfacher! Die folgende Abfrage gibt verschiedene Zahlen ...

SELECT COUNT (*) FROM Tabelle

ich darüber nachzudenken, ob es zu irgendeiner Form von Caching und/oder unsachgemäßen Transaktionsmanagement von einer anderen Anwendung verwendet ist, die gelegentlich die Daten auffüllt .

Answer 1

Das Problem wurde zwischen einem Upgrade auf Access 2007 und dem Herunterladen einer neuen Kopie der Datenbank von der Quelle gelöst. Ich weiß immer noch nicht, was die Ursache war, aber ich vermute eine Form der Indexbeschädigung.

Answer 2

Können Sie uns eine verschleierte Datenbank geben, die dieses Problem anzeigt? Das habe ich noch nie erlebt. Geben Sie zumindest die Tabellendefinitionen an - sind irgendwelche der Spalten schwebend oder dezimal?

Answer 3

Das klingt vielleicht dumm. Aber ...

Ist der Pfad zur tatsächlichen Datenbank & Verbindungszeichenfolge (DSN) auf dieselbe Dateiposition zeigen?

Answer 4

Haben Sie das gleiche Problem mit anderen ODBC-Tools, zum Beispiel Query Tool? Sie können die ODBC-Ablaufverfolgung auch im ODBC-Verbindungs-Manager aktivieren. Ich habe keinen Zugang und weiß nicht, ob seine SQL-Befehle verfolgt werden, aber manchmal hilft es mir, ODBC-Probleme zu lösen.

Answer 5

Sind die Felder indiziert? Ist dies der Fall, ist möglicherweise einer der Indizes beschädigt und Sie müssen die MDB-Datei komprimieren. Wenn ein Index beschädigt ist, kann dies zu schwerwiegenden Problemen führen. Sie könnten bestehende Beziehungen verlieren (wenn der korrupte Index der PK ist), oder Sie könnten Daten verlieren. Sie müssen also ein Backup haben, bevor Sie das tun.Wenn es einen beschädigten Index gibt, denke ich, dass die interaktive Access-Komprimierungsoperation Ihnen das sagen wird, aber wenn nicht, können Sie nach der MSysCompactErrors-Tabelle suchen, die Ihnen sagen wird, welche Fehler während des Komprimierens aufgetreten sind.

Dieses nur sehr selten vorkommt und eine von zwei Dinge zeigen kann:

1. schlechtes Anwendungsdesign, einschließlich veralteter Jet-Versionen (Jet 4 vor dem Service Pack 6 bis diese sehr anfällig war, und das ist, wo ich gestoßen es).

2. unzuverlässige Betriebsumgebung (Netzwerk/Hardware/Software).

Natürlich ist dieser Vorschlag ein echter Totalen, aber es ist auf jeden Fall eine Ursache für unterschiedliche Ergebnisse (die häufigste wäre auf dem beschädigten Index ORDER BY und Sie werden mit einem anderen Datensatz am Ende zählen als mit einer anderen ORDER BY).

Answer 6

Ich vermute, das Problem könnte sein, dass Sie die Abfrage nicht festgeschrieben haben. PYODBC startet mit autocommit = False und daher startet jede Abfrage wie select, insert, update usw. eine Transaktion, die Sie ausführen müssen, um Wirkung zu erzielen. Entweder rufen Sie connection.autocommit = True oder rufen Sie cursor.execute("commit") nach der Abfrage und dann fetchall.