Discussion :

[hamerpote]

Bonjour à tous,

comme indiqué dans l'intitulé de ce message, après avoir exécuté plusieurs fois des importations via ODBC (Suppression et chargement) les tables liées avec index affichent systématiquement dans tous les champs #supprimé#.

Petite description:

- Les tables sont créées dans deux instances SQL Server Express 2012 (en phase de test) - Update et Consult.
- Ces tables disposent de plusieurs champs indexés et d'un PRIMARY INDEX de type IDENTITY (compteur auto incrémenté)
- Les mêmes tables sont attachées via ODBC pilote "SQL Server 6.03.9600.16384" dans deux clients bases de données Ms Access - interfaces utilisateurs de Mises à jour et de consultations.
- Dans la base de consultation sans index (pour interdire les mises à jour) et dans la base update avec l'index IDENTITY (à l'inverse, autoriser les mises à jour)
- Le chargement des tables SQL est de type "massif" et journalier, +/- 800.000 enregistrements tous normalisés au format caractères (Collectes de différentes sources d'informations)
- La préparation de ces enregistrements, ce fait via du code VBA dans MS Access et des scripts VBS en utilisant ADODB et /ou ODBC pour les mises à jour.
- La réplication des tables mises à jour d'une instance vers l'autre, se fait via ADODB en mode BATCH (assez rapide tenant compte du volume à traiter)

Comme le rafraichissement des données est total, les tables sont effacées via une requête TRUNCATE TABLE xxx avant d'être chargées.
L'option TRUNCATE est plus rapide qu'un DELETE classique et surtout elle réinitialise l'index IDENTITY automatiquement.

Le problème est qu'après plusieurs tests, au niveau MS Access (2003, 2007 ou 2013 via des machines virtuelles pour ne pas mélanger les version MS Office) les tables affichent systématiquement dans tous les champs #Supprimé#. Pourtant au niveau SQL, elles sont chargées correctement, idem via consultation avec WINSQL.

Précision : Uniquement dans la base MS Access où les tables sont attachés avec l'index IDENTITY. Au niveau consultation pas de problèmes, car les tables n'ont pas de référence à cet index.

Visiblement ce problème semble lié à ce fameux index, pourtant tout fonctionnait bien au début. Après des heures et des heures de recherche, de DBCC CLEANTABLE, CHECKTABLE, CHECKDB et autres fantaisies, le seul moyen de retrouver une situation normale est de recréer les tables ayant cet index particulier.

En phase de test, ceci ne pose pas de problèmes, mais je ne peux me permettre de recréer systématiquement les tables (trop de contraintes au niveau sécurité)
En fait, la partie consultation n'est pas véritablement impactée, mais dans la base update où sont attachée toutes les tables avec index, même si les données sont physiquement correctes au niveau SQL, l'affichage sous MS Access ne l'est pas.

J'oubliais et je pense que ceci a son importance, dans MS Access :

- Lorsque j'ouvre une table liée avec index (ou une requête) et voyage dans les différents champs, je peux visualiser la valeur correcte du champs sélectionné, mais dès que je passe à un autre champs, le précédent réaffiche #Supprimé# (uniquement sur le premier enregistrement de la série affichée "qui n'est pas forcément le premier enregistrement dans la base de données SQL)
- Je peux modifier la valeur des champs, mais avec toujours ce même affichage après MAJ (Alors que sous SQL Server, les données sont bien modifiées)
- Lorsque je supprime la table et relie cette dernière sans index ou en créant un index virtuel sur un autre champs, à ce moment l'affichage est correct.

Est-ce un problème ODBC ou une mauvaise gestion de ce type d'index par MS Access, je ne sais pas et je commence à bloquer (alors que l'ensemble est pratiquement terminé)

Si quelqu'un aurait connaissance de ce problème spécifique, une solution ou même des informations à ce sujet. Je suis preneur à 200%.
(Je n'ai vraiment pas envie de reconstruire le modèle de données après 2 mois de développement sous MS Access et portage sur SQL Server)

Dans l'attente d'une réponse (positive ou négative) D'avance un grand merci..

[hamerpote]

En analysant les toutes les tables à tête reposée, j'ai trouvé l'erreur (et c'est de ma faute)

J'ai chargé plusieurs fois certaines tables avec l'outil BCP et curieusement le type du champs IDENTITY est passée de "int" à "bigint" sur SQL Server.
(En réalité, erreur de définition dans le fichier FMT utilisé)

MS Access semble interprèter "bigint"comme du Texte(255) et non comme NuméroAuto avec "int".
voilà certainement pourquoi l'affichage était anormale, n'ayant pas la référence adéquate et que du coté SQL Server tout était correct.

Après correction, tout est ok maintenant.

Mille excuses.