none
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


    dimanche 1 septembre 2013 14:42

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

    jeudi 5 septembre 2013 07:25

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.


    lundi 2 septembre 2013 08:47
  • 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 : Professional

    Microsoft 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

    Est-ce-que je peux l'installer ?

    lundi 2 septembre 2013 13:28
  • 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.

    mardi 3 septembre 2013 08:00
  • 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.

    mardi 3 septembre 2013 13:01
  • Bonjour,

    J'ai essayé ! Mais à chaque fois que je clique sur le bouton "ENVOYER3, j'ai l'erreur :

    * Tous les champs sont obligatoires

    ? J'ai pourtant tout remplit

    Cordialement

    SC


    Cordialement SC

    mardi 3 septembre 2013 13:11
  • Bien vue ....  Mais j'ai fait le test .....

    SC


    Cordialement SC

    mardi 3 septembre 2013 13:13
  • 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.

    mercredi 4 septembre 2013 12:11
  • 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

    mercredi 4 septembre 2013 15:18
  • 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


    jeudi 5 septembre 2013 07:02
  • 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

    jeudi 5 septembre 2013 07:25
  • 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

    jeudi 5 septembre 2013 14:24
  • 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

    jeudi 5 septembre 2013 15:17