Meilleur auteur de réponses
Visual Studio 2008 Access 2003 – Sauvegarde ou copie de la base

Question
-
Bonjour,
J'ai consulté le "thread Sauvegarde Base de Donnée", mais il ne correspond pas à mon problème
Je donne l'essentiel du projet
J'ai une base Individu avec deux tables. Principale et Analyse
Pour les deux, même descriptif. Fiche individu : Clef (unique) Nom Prénom
Je créé la table Principal à partir d'un fichier texte
Je créé la table Analyse à partir d'un autre fichier texte
Je ferme la base, et la copie sous un autre nom, IndividuSauve
J'ouvre la base, et appareille les deux tables, c’est-à-dire que je créé un fichier texte avec les individus des deux tables, en éliminant les fiches de la table Analyse qui ont le même nom et prénom que celles de la table Principale
En fin, je donne la possibilité de recommencer l'appareillage des deux tables
Pour cela, je ferme la base Individu et copie IndividuSauve sous le nom d'Individu
(Je rétablis donc Individu d'origine)
À ce moment, la table Analyse comporte des erreurs
Voici la copie d'écran
Quand que clique sur le champ #Erreur, j'ai le message suivant
Voici la copie d'écran
Quand je clique sur Aide, j'ai le texte suivant
Le moteur de base de données Microsoft Jet a arrêté le traitement parce que vous et un autre utilisateur tentez de modifier
les mêmes données en même temps. (Erreur 3197)
Cette erreur survient dans un environnement multi-utilisateur.Un autre utilisateur a modifié les données que vous essayez de mettre à jour.
Cette erreur survient lorsque plusieurs utilisateurs ouvrent une table ou créent un Recordset et utilisent un verrouillageoptimiste.
Entre le moment où vous avez utilisé la méthode Edit et la méthode Update, un autre utilisateur a modifié les mêmes données.Pour remplacer les modifications de l'autre utilisateur par les vôtres, exécutez à nouveau la méthode Update
Optimiste
Type de verrouillage dans lequel la page de données contenant un ou plusieurs enregistrements,
y compris l'enregistrement en cours de modification,
n'est pas disponible pour les autres utilisateurs lorsque cet enregistrement est mis à jour à l'aide de la méthode Update,
mais est disponible entre l'utilisation des méthodes Edit et Update.
Le verrouillage optimiste est utilisé lors d'accès aux bases de données ODBC ou lorsque la propriété LockEdits de l'objet Recordset a la valeur False
optimiste
Type de verrouillage dans lequel la page de données contenant un ou plusieurs enregistrements,
notamment l'enregistrement en cours de modification,
n'est pas disponible pour les autres utilisateurs lorsque cet enregistrement est mis à jour à l'aide de la méthode Update,
mais est disponible entre l'utilisation des méthodes Edit et Update.
Le verrouillage optimiste est utilisé lors d'accès aux bases de données ODBC (Open DataBase Connectivity)
ou lorsque la propriété LockEdits de l'objet Recordset a la valeur False.Je suis en mono poste, mono utilisateur (En fait, je ne sais pas comment définir ces options)
Voici le code d'ouverture de la base
Public Sub ConnectionBase() Try dbConn = "Provider=Microsoft.Jet.OLEDB.4.0 ; Data Source = " & MaBase & " ; Persist Security Info=False; Jet OLEDB:Database Password=MotDePasse;" dbCnx = New OleDbConnection dbCnx.ConnectionString = dbConn dbCnx.Open() Catch ex As Exception MsgErreur = "WmodBaseDonne - ConnectionBase " & vbCrLf & " Erreur dans la connection à la base de donnée" & vbCrLf & ex.Message wOK = False Anomalie.ShowDialog() Exit Sub End Try End Sub
Si je ne rétablis pas la base, je n'ai pas ce type d'erreur
(Mais bien sur la logique métier n'est pas respectée …)
Avez-vous une idée sur ce dysfonctionnement ?
Cordialement
SC
Cordialement SC
- Modifié Sauveur Consalvi jeudi 5 septembre 2013 06:55 erreur dans Titre
Réponses
-
Juste une petite remarque : il me semble que votre approche est mauvaise (désolé, je veux pas vous vexer ;-)).
Essayez d'avoir une approche "plus" base de données, c'est-à-dire qu'au lieu de gérer plusieurs bases de données, n'en gérer qu'une. Ainsi, c'est le moteur jet qui sera mis en cause en cas de problème plutôt que votre code (ex: faut TOUJOURS faire un myConnection.Close() ou myConnection.Dispose() même si il y a une exception).
A partir de là, vous pouvez très bien utiliser des tables temporaires pour effectuer vos manipulations (faudra juste apprendre un peu le SQL).
En plus, vous pourrez effectuer des opérations complexes avec une seule requête SQL qui sera beaucoup plus performante qu'un quelconque code managé.
Mais je sais, ca demande une grosse remise en question de votre code.
Richard Clark
Consultant - Formateur .NET
http://www.c2i.fr
Depuis 1996: le 1er site .NET francophone- Marqué comme réponse Sauveur Consalvi jeudi 5 septembre 2013 15:13
Toutes les réponses
-
Bonjour
Pouvez-vous vérifier si c'est bien votre cas?
http://support.microsoft.com/kb/182867/fr
Cordialement,
Aurel BERA, MSFT
MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.- Modifié Aurel Bera lundi 2 septembre 2013 08:49
-
Bonjour,
Effectivement, cela ressemble, puisque j'ai l'erreur 3197, et c'est bien dans un champ MEMO
De plus, cette erreur est aléatoire
Mais le lien donné parle de JET 3.0
Moi je suis en Microsoft.Jet.OLEDB.4.0 , et Microsoft Office Access 2003 (11.8321.8403) SP3
D'ailleurs je ne trouve pas msjet35.dll sur mon PC
J'ai reproduit l'incident. J'ai ouvert la base avec cet incident sous Access, et j'ai compacté la base.
Je n'ai pas de menu "Réparer une base de données)
Après le compactage, pour les articles en incidents, le champs MEMO contient ##########, mais pas les informations !
Je ne vois pas ce qui peut provoquer cela, car si je travaille sur la même base je n'ai pas l'incident
Je ne l'ai que si copie la base sauvegardée sur cette base
J'aimerai bien trouver, car cela rend mon projet "douteux"
Cordialement
SC
Microsoft Visual Studio 2008
Version 9.0.21022.8 RTM
Microsoft .NET Framework
Version 3.5 SP1
Édition installée : ProfessionalMicrosoft Office Access 2003 (11.8321.8403) SP3
Windows 8 Professionnel 64 bits, processeur x64
-------------------------------------------------------
Je modifie ma réponse car j'ai trouvé un patch
http://www.microsoft.com/fr-fr/download/details.aspx?id=7151
Mais il ne parle que d'ancienne version de Windows
- Modifié Sauveur Consalvi lundi 2 septembre 2013 13:42
-
Je dirais que non. Ce patch n'existe pas pour les versions Vista, 7, 8 .
Donc je conclus que la correction c'est déjà incluse.
Aussi essayez de poster votre question sur les forums Community: http://answers.microsoft.com/fr-fr/office/forum
J'ai vu que c'est un problème commune, et peut-être les MVP Office peut vous aider.
Cordialement,
Aurel BERA, MSFT
MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution. -
J'ai revu ce thread.
Vous utilisez un fichier Access 97 avec Access 2003 installée sur votre PC.
Peut-être ici c'est le problème.
Pouvez-vous faire un test et l'enregistrer "à main" en format Access 2003?
Cordialement,
Aurel BERA, MSFT
MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution. -
-
-
Bonjour de nouveau.
Pouvez-vous faire une réparation et compactage pour la BD initiale?
Merci,
Cordialement,
Aurel BERA, MSFT
MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution. -
Bonjour,
J'ai fait ce test. Je vais recréer complétement la base et relancer
Je vous tiens au courant
Pour poster sur le forum office, j'ai toujours le message d'erreur (Depuis 2/3 jours)
"Désolé, impossible de traiter la requête. Veuillez réessayer plus tard. "
Cordialement
SC
Cordialement SC
-
Bonjour,
J'ai modifier le titre, car je ne sais pourquoi j'ai parlé d'ACCESS 97
C'est bien ACCESS 2003
J'ai construit manuellement une nouvelle base, et j'ai refait le test avec celle-ci
Idem ....
Je vous livre ce post trouvé sur le forum de Codes-Sources
http://codes-sources.commentcamarche.net/forum/affich-818203-plantage-galere-d-access
Entre autre :
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 ?Il y a surement un problème avec les champs MEMO sous ACCESS
Pour le moment, c'est la première fois que j'ai cette erreur
Je reviendrais vers vous si elle se renouvelle
Cordialement
SC
Cordialement SC
- Modifié Sauveur Consalvi jeudi 5 septembre 2013 07:03 erreur de frappe
-
Juste une petite remarque : il me semble que votre approche est mauvaise (désolé, je veux pas vous vexer ;-)).
Essayez d'avoir une approche "plus" base de données, c'est-à-dire qu'au lieu de gérer plusieurs bases de données, n'en gérer qu'une. Ainsi, c'est le moteur jet qui sera mis en cause en cas de problème plutôt que votre code (ex: faut TOUJOURS faire un myConnection.Close() ou myConnection.Dispose() même si il y a une exception).
A partir de là, vous pouvez très bien utiliser des tables temporaires pour effectuer vos manipulations (faudra juste apprendre un peu le SQL).
En plus, vous pourrez effectuer des opérations complexes avec une seule requête SQL qui sera beaucoup plus performante qu'un quelconque code managé.
Mais je sais, ca demande une grosse remise en question de votre code.
Richard Clark
Consultant - Formateur .NET
http://www.c2i.fr
Depuis 1996: le 1er site .NET francophone- Marqué comme réponse Sauveur Consalvi jeudi 5 septembre 2013 15:13
-
Bonjour,
Non, je ne me vexe pas, car je sais que mon code pour gérer les bases n'est pas le terrible ...
A ma décharge, il m'a fallut un temps fou pour trouver les informations ...
Je compte bien réécrire
Mais d'un autre coté, la fermeture à été "revu et corrigée" par le forum, car j'avais des problèmes
A la fin du premier traitement, je ferme la base, je la copie sur un autre nom, et j'ouvre de nouveau
La copie se fait par
My.Computer.FileSystem.CopyFile(MaBase, MaBaseAvantFusion, True)
Ceci dit, c'est peut être bien mon code qui est responsable
Je vais, avant de réécrire, l'analyser en profondeur
Cordialement
SC
Cordialement SC
-
J'ai ajouté un compactage de la base après le "rechargement"
Je ne suis pas sur que cela soit LA solution, mais manifestement, quand je ne le fait pas, j'ai l'erreur, quand je le fait, je n'ai plus l'erreur
Donc, il faut bien "penser" la code ...
Mes remerciements à tous
Cordialement
SC
Cordialement SC