Plantage galère d'ACCESS
tedparker
Messages postés
176
Date d'inscription
mercredi 5 mai 2004
Statut
Membre
Dernière intervention
25 septembre 2006
-
25 sept. 2006 à 11:27
cs_adagio Messages postés 1 Date d'inscription jeudi 16 janvier 2003 Statut Membre Dernière intervention 13 janvier 2009 - 13 janv. 2009 à 20:37
cs_adagio Messages postés 1 Date d'inscription jeudi 16 janvier 2003 Statut Membre Dernière intervention 13 janvier 2009 - 13 janv. 2009 à 20:37
3 réponses
cs_Visso
Messages postés
36
Date d'inscription
samedi 8 juin 2002
Statut
Membre
Dernière intervention
17 avril 2014
5 oct. 2006 à 09:42
5 oct. 2006 à 09:42
Utilise un utilaire appelé jetcomp pour réparer ta base access à moins quelle ne soit totalement gâtée.
VISSO
VISSO
cs_Visso
Messages postés
36
Date d'inscription
samedi 8 juin 2002
Statut
Membre
Dernière intervention
17 avril 2014
5 oct. 2006 à 09:43
5 oct. 2006 à 09:43
Utilise un utilaire appelé jetcomp pour réparer ta base access à moins quelle ne soit totalement gâtée.
VISSO
VISSO
cs_adagio
Messages postés
1
Date d'inscription
jeudi 16 janvier 2003
Statut
Membre
Dernière intervention
13 janvier 2009
13 janv. 2009 à 20:37
13 janv. 2009 à 20:37
Bonjour
Ayant l'habitude de consulter les forums techniques pour y trouver l'aide nécessaire à des développements VB complexes, il me parait utile de vous faire part de mon experience concernant la résolution de l'erreur Access 3197 avec le moteur Jet, les milliers de messages concernant ce sujet se limitant à la réparation de la base avec jetcomp. N'y ayant pas trouvé comment éviter le problème, j'ai fais de très nombreux tests et...
Voici donc le résumé :
1 - Une grosse base de données Access 2 sous VB6 jusque là sans probleme, et au passage sous Vista, massacre de la base avec cette erreur 3197 en monoposte de manière aléatoire.
2 - La base en Access 97, ou Access 2000 m'a produit le même désastre
3 - Doutant de la couche Wdac, j'ai donc tenté d'utiliser un verouillage pessimiste, qui a semblé corriger le problème, mais... le problème s'est posé alors sur certaines stations XP, en couche MDAC de dernière version MDAC 2.8 SP1 (problème que je n'avais étrangement pas sur ma propre machine XP de même niveau de MDAC, JET et SP).
4 - J'ai alors modifié les accès pour rafraichir le cache et forcer et libérer les verrous par les dbengine.idle (dbrefreshcache et dbfreelocks) après les .INDEX, .SEEK, .UPDATE, sans succès particulier
5 - Mais, lors d'un traitement affichant le contenu immédiat de chaque enregistrement ajouté, j'ai constaté qu'un champ mémo pourtant variable de contenu, restait similaire : en tracant le pourquoi, j'ai constaté qu'en effet, immediatement après un .ADDNEW sur un recordset, certains champs mémos n'étaient ni nuls ni vides, mais encore emplis d'une précédente valeur !... et ce d'ailleurs malgré un dbengine.dle dbrefreshcache
6 - J'ai donc faire suivre chaque .addnew d'une affectation d'une chaine vide (vbnullstring) à chaque champ mémo, ce qui apparait normalement comme complètement inutile.
Et le problème a disparu !
J'en déduis donc qu'il y a bien un gros problème de gestion du cache des champs mémo dans un recordset access jet, mais que le problème est contournable en ne faisant pas confiance au simple .addnew pour obtenir une fiche vide. Affecter dès la création des valeurs vides à chaque champ mémo est fastidieux, mais apparemment efficace, puisque le moteur jet ne remplit plus les champs mémos avec n'importe quoi lors de l'update. Evidemment, je suppose que si tous les champs mémos sont assignés avant le update le problème ne doit pas se produire, mais si par malheur un champ n'a pas été spécifiquement défini...
Si vous avez ce même type d'expérience désatreuse, pouvez-vous me confirmer si cette simple affectation systématique immédiatement après les addnew à résolu votre problème ?
Ayant l'habitude de consulter les forums techniques pour y trouver l'aide nécessaire à des développements VB complexes, il me parait utile de vous faire part de mon experience concernant la résolution de l'erreur Access 3197 avec le moteur Jet, les milliers de messages concernant ce sujet se limitant à la réparation de la base avec jetcomp. N'y ayant pas trouvé comment éviter le problème, j'ai fais de très nombreux tests et...
Voici donc le résumé :
1 - Une grosse base de données Access 2 sous VB6 jusque là sans probleme, et au passage sous Vista, massacre de la base avec cette erreur 3197 en monoposte de manière aléatoire.
2 - La base en Access 97, ou Access 2000 m'a produit le même désastre
3 - Doutant de la couche Wdac, j'ai donc tenté d'utiliser un verouillage pessimiste, qui a semblé corriger le problème, mais... le problème s'est posé alors sur certaines stations XP, en couche MDAC de dernière version MDAC 2.8 SP1 (problème que je n'avais étrangement pas sur ma propre machine XP de même niveau de MDAC, JET et SP).
4 - J'ai alors modifié les accès pour rafraichir le cache et forcer et libérer les verrous par les dbengine.idle (dbrefreshcache et dbfreelocks) après les .INDEX, .SEEK, .UPDATE, sans succès particulier
5 - Mais, lors d'un traitement affichant le contenu immédiat de chaque enregistrement ajouté, j'ai constaté qu'un champ mémo pourtant variable de contenu, restait similaire : en tracant le pourquoi, j'ai constaté qu'en effet, immediatement après un .ADDNEW sur un recordset, certains champs mémos n'étaient ni nuls ni vides, mais encore emplis d'une précédente valeur !... et ce d'ailleurs malgré un dbengine.dle dbrefreshcache
6 - J'ai donc faire suivre chaque .addnew d'une affectation d'une chaine vide (vbnullstring) à chaque champ mémo, ce qui apparait normalement comme complètement inutile.
Et le problème a disparu !
J'en déduis donc qu'il y a bien un gros problème de gestion du cache des champs mémo dans un recordset access jet, mais que le problème est contournable en ne faisant pas confiance au simple .addnew pour obtenir une fiche vide. Affecter dès la création des valeurs vides à chaque champ mémo est fastidieux, mais apparemment efficace, puisque le moteur jet ne remplit plus les champs mémos avec n'importe quoi lors de l'update. Evidemment, je suppose que si tous les champs mémos sont assignés avant le update le problème ne doit pas se produire, mais si par malheur un champ n'a pas été spécifiquement défini...
Si vous avez ce même type d'expérience désatreuse, pouvez-vous me confirmer si cette simple affectation systématique immédiatement après les addnew à résolu votre problème ?