PyODBC et Microsoft Access: Résultats incohérents d'une requête simple

Question

J'utilise pyodbc, via Microsoft Jet, pour accéder aux données d'une base de données Microsoft Access 2003 à partir d'un programme Python.

La base de données Microsoft Access provient d'un tiers; Je ne fais que lire les données.

J'ai généralement réussi à extraire les données dont j'ai besoin, mais j'ai récemment remarqué quelques divergences.

J'ai fait bouillir vers le bas à une simple requête, de la forme:

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

J'ai obscurcie les noms des champs et des valeurs, mais vraiment, il ne va pas beaucoup plus trivial que cela! Lorsque j'exécute la requête dans Access, il renvoie un enregistrement.

Puis je l'exécuter sur pyodbc, avec le code qui ressemble à ceci:

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

(Encore une fois, il ne va pas beaucoup plus trivial que ça!)

La valeur de queryString est coupée -et-collé à partir de la requête de travail dans Access, mais il renvoie aucun enregistrements. Je m'attendais à ce qu'il retourne le même disque.

Lorsque je change la requête pour rechercher une valeur différente pour field2, bingo, cela fonctionne. Ce sont seulement certaines valeurs qu'il rejette.

Alors, aidez-moi s'il vous plaît. Où devrais-je regarder pour expliquer cette divergence? Si je ne peux pas faire confiance aux résultats de requêtes triviales, je n'ai aucune chance sur ce projet!

Mise à jour: Cela devient encore plus simple! La requête suivante donne des chiffres différents ...

SELECT COUNT (*) FROM table

je médite si elle est liée à une certaine forme de mise en cache et/ou une mauvaise gestion des transactions par une autre application que, parfois, à des données renseigne la .

Answer 1

Le problème a été résolu quelque part entre une mise à niveau vers Access 2007 et le téléchargement d'une nouvelle copie de la base de données à partir de la source. Je ne sais toujours pas quelle était la cause première, mais je soupçonne une forme de corruption d'index.

Answer 2

pouvez-vous nous donner une base de données obfuscated qui montre ce problème? Je n'ai jamais vécu ça. Au moins donner les définitions de la table - est-ce que l'une des colonnes est flottante ou décimale?

Answer 3

Cela peut sembler stupide. Mais ...

Le chemin vers la base de données & pointe-t-il vers le même emplacement de fichier?

Answer 4

Avez-vous le même problème avec d'autres outils ODBC, par exemple Query Tool? Vous pouvez également activer le suivi ODBC dans ODBC Connection Manager. Je n'ai pas accès et je ne sais pas si ses commandes sql seront tracées mais parfois cela m'aide à résoudre des problèmes ODBC.

Answer 5

Les champs sont-ils indexés? Si c'est le cas, l'un des index est peut-être corrompu et vous devez compacter le fichier MDB. Si un index est corrompu, cela peut entraîner des problèmes majeurs. Vous pourriez perdre des relations existantes (si l'index corrompu est le PK), ou vous pourriez perdre des données. Vous devez donc avoir une sauvegarde avant de faire cela.S'il existe un index corrompu, je pense que l'opération interactive Access compact vous le dira, mais si ce n'est pas le cas, vous pouvez rechercher la table MSysCompactErrors qui vous indiquera quelles erreurs se sont produites pendant le compactage.

Cela ne se produit que très rarement et peut indiquer l'une des deux choses:

1. mauvaise conception d'applications, y compris obsolètes versions Jet (Jet 4 avant Service Pack 6 a été très sensible à cela, et c'est là que je rencontrais il).

2. environnement d'exploitation non fiable (réseau/matériel/logiciel).

Bien sûr, cette suggestion est un vrai coup long, mais il est certainement une cause de résultats différents (serait le plus commun est à l'ordre par l'indice corrompu et vous finirez avec un autre dossier compter qu'avec un autre ORDER BY).

Answer 6

Je suppose que le problème peut être que vous n'avez pas validé la requête. PYODBC commence par autocommit = False et par conséquent chaque requête comme select, insert, update etc. lancera une transaction qui, pour obtenir l'effet que vous avez à valider. Appelez connection.autocommit = True ou appelez cursor.execute("commit") après la requête, puis fetchall.