Portail PHP

J'ai le même problème avec une requête de suppression beaucoup plus simple (DELETE FROM Account WHERE FinancialYearID=xxx), mais en passant par VB et par une connexion ADO.
Le problème se produit que sur un poste particulier (l'application tournant sur au moins 5 postes dans deux pays, Suisse et France).
Impossible de trouver une réponse sur le web, seul ton message sur ce forum en fait le cas.
:?

P.S: Moi j'ai pas le *.

Tout à fait. La question serait alors quel couche logicielle est concernée. PHP utilise ODBC pour accéder à la base Access, moi c'est ADO.

Tous mes clients sont sur Windows XP, mais je ne sais pas si SP2 ou pas.
Alors, qu'est-ce qui embête ? - ADO, ODBC, Jet, la version linguistique d'un de ceux-cis, le SP2 ? - Pas évident.

En espérant que quelqu'un le découvre avant, je continues mes recherches occasionnelles et si je trouve je posterai mes résultats ici.

"Parturient Montes" 

Très judicieuse remarque.

Des premiers éléments concernant la machine victime me sont parvenus.
Y a bien un XP+SP2 (je sais pas si c'est une édition Pro ou Home), mais à vrai dire, c'est le cas de toutes les autres machines aussi, et elles ne posent pas de problèmes.
Office 2003 est aussi installé sur la machine.

D'autres vérifications sont en cours (patches Office appliqués, mises-à-jour du système post SP2 appliquées ou mancantes, etc...).

La suite bientôt.

C'est encore plus simple, ce sont des postes autonomes.
Les bases Access sont locales (sur la machine même, sur chaque poste).

En fait, il y a un programme qui exporte et importe les données en passant par du XML (utilise MSXML3). C'est à l'importation que j'ai le problème sur un poste.

Le dénouement final
Le problème a disparu aujourd'hui. Aussi simplement et rapidement qu'il est apparu d'ailleurs.
L'utilisateur a simplement remplacé sa base par un backup et les données à importer sont passées comme une lettre à la poste et les imports-exports se passent bien désormais.

Malheureusement, je n'ai pas pu avoir une copie de sa base posant un problème et je n'ai pu reproduire le problème.

Je crois que c'est fichu pour savoir d'où ça pouvait venir, à moins qu'il se remanifeste. Tant pis... ou tant mieux, on verra!

Merci à tous.

P.S: juste pour l'historique, voici un petit extrait des journaux d'importation. Juste les messages d'erreurs en question:

...
2005-06-01,10:45:49,ER,-2147217887,XPortImportAccts,La clé de recherche n'a été trouvée dans aucun enregistrement.,
...
2005-06-01,11:04:29,EV,0,DELETEFINYEAR,Suppression des données et structures de l'exercice existant (#33),
2005-06-01,11:04:29,ER,16389,DeleteFinancialYear,Suppression des comptes¶16389: La clé de recherche n'a été trouvée dans aucun enregistrement.,
...

Très bien vu.
C'est vrai que ça commence plus à sentir les données non compatibles .
En fait, pour me protégér de ce genre de problèmes, j'inscrit toujours ma version de la structure de la base de données dans la base elle-même; voici par exemple le script SQL de la dernière mise-à-jour (février 2005):

// V01.01.33 (Update)
// code societe
ALTER TABLE Company ADD COLUMN  CompanyCode VARCHAR(25);
INSERT INTO DBVersion(VersionNumber) VALUES ('01.01.33');

(Je fais tout par scripts SQL)
Mais comme j'ai pas la base de données en question, ben j'peux pas le vérifier. Bah !