none
Base de données verrouillée RRS feed

  • Question

  • Bonjour,

    Je travaille sur une application développée avec Access 2013. Je n'utilise aucune macro mais beaucoup de code VBA. Je suis le seul utilisateur de la base de données sur mon appareil et n'ai aucun autre appareil en réseau.

    Mon application est scindée en deux fichiers, soit un pour les objets (formulaires, états, modules) et un autre qui ne contient que les tables qui sont attachées au premier fichier.

    Lorsque je développe les formulaires et le code VBA, tout se passe sans problème. De temps à autre, je teste les modifications effectuées en lançant l'application et en ajoutant ou supprimant des enregistrements. Dès lors, il m'est impossible de faire quelque modification que ce soit aux formulaires ou modules (je n'ai aucun état développé à date).

    Lorsque je tente de modifier un formulaire ou module, je reçois le message suivant :
    Vous n'avez pas les autorisations requises pour accéder à la base de données. Si vous faites des modifications, elles ne pourront pas être enregistrées.

    Si je force les choses et tente quand même de faire des modifications, lorsque je tente d'enregistrer les modifications, je reçois le message suivant :
    ... ne peut pas enregistrer les modifications de conception ou effectuer un enregistrement dans un nouvel objet de base de données car le fichier est ouvert par un autre utilisateur. Pour effectuer l'une ou l'autre opération, vous devez disposer d'un accès exclusif au fichier.

    Comme mentionné, la base de données n'est ouverte par personne d'autre que moi-même. J'ai ouvert la base de données en mode exclusif avec les mêmes résultats. La seule façon que j'ai trouvée est de fermer la base de données et de l'ouvrir à nouveau, ce qui devient très agaçant à la longue.

    Si quelqu'un a une solution à ce problème, je serais plus qu'enchanté de la connaître.

    Merci à tous !

    mardi 25 février 2014 22:59

Réponses

  • Bonjour,

    Plusieurs hypothèses peuvent justifier d'un tel comportement...

    Du fait que vous soyez la personne qui reprenne le développement de cette application, il est fort probable que vous ne connaissiez pas tous les tenants et aboutissants qui la constituent.

    En d'autres termes, dans un premier temps je vous préconiserais volontiers de rapatrier les deux fichiers en local et de travailler dans un répertoire de développement spécifiquement dédié à cet effet car il est probable que ce soit dû à des problèmes de droits sur le dossier réseau.

    Une fois cela fait, vous procédez au rattachement des tables de manière à ce que l'application frontale pointe vers la base de données dorsale sur l'ensemble des tables. 

    Lorsque cela est opérationnel, il est fort probable que la conception de cette application est été effectuée par quelqu'un qui ne maîtrisait pas par exemple le mode d'ouverture des jeux d'enregistrement ou encore les interactions qui peuvent agir et survenir entre deux tables ayant des relations.

    De ce fait, je vous proposerais volontiers de d'ouvrir tous les formulaires liés à une requête en mode création afin de vérifier le mode d'ouverture, les requêtes en elle-même, mais également les instructions VBA qui sollicitent le type de Recordset associé au formulaire, celui-ci pouvant avoir des incidences sur le comportement global de l'application.

    Il se peut aussi que au sein du code VBA du projet existent des appels d'instances qui ouvrent en mode exclusif par exemple la base de données dorsale et donc provoque bien entendu un échec lorsque vous tentez de modifier tel ou tel objet.

    Là, il vous faut regarder du côté des mots clé comme OpenDatabase...

    Enfin et surtout, je vous propose d'insérer dans les procédures et fonctions, de gestions d'erreur musclées associées à la possibilité de stopper le code en cas d'erreur grâce à l'instruction Stop couplée à l'instruction Resume qui vous permettra de reprendre la main et de comprendre l'éventuelle erreur et sa cause. Pour ce faire, vous pouvez user d'une constante publique qui vous permettrait de passer du mode débogage au mode mis en Prod de par la simple valeur True ou False.

    Exemple :

    Public Const MODE_DEBOGAGE = True
    
    Public Sub UneProcedure()
    
        On Error Goto UneProcedureErr
        [...]
    UneProcedureSortie:
        Exit Sub
    UneProcedureErr:
        If MODE_DEBOGAGE  Then
            Stop
            MsgBox Err.Description, , Err.Number
            Resume
        Else
            Resume UneProcedureSortie
        End If
    En Sub

    Une fois localisé votre problème, vous mettez en oeuvre une procédure de rattachement automatique des tables.


    Argy


    mercredi 5 mars 2014 09:54
    Modérateur

Toutes les réponses

  • Bonjour

    Le fichier nom_db.ldb est présent dans le répertoire ou la BD se trouve?
    Essayez de le supprimer.

    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.

    jeudi 27 février 2014 10:11
  • Merci pour votre aide.

    Je connais l'utilité du fichier .ldb ou .laccdb dans mon cas et j'avais déjà vérifié qu'il est supprimé lorsque je ferme Access.

    Entretemps, j'ai fait un petit test : plutôt que d'utiliser des tables attachées j'ai importées les tables dans la base de données contenant les objets de programmation, formulaires, états et modules. Le problème est disparu instantanément.

    J'en déduis donc que c'est la base de données contenant les tables attachées qui causait le problème. Je ne m'explique pas pourquoi. Sauf que le projet en question me vient d'un autre programmeur qui n'arrivait pas à le terminer. Je n'ai utilisé que les tables de son projet et reconstruit à neuf formulaires, états et modules.

    Je travaille sur un autre projet que j'ai développé à partir du début. J'utilise des tables attachées et je n'ai pas le problème mentionné dans mon premier message.

    Si je ne peux trouver de solution au problème, je devrai développer avec les tables importées et les exporter à la fin pour fonctionner avec des tables attachées en environnement de travail.

    Encore merci de votre aide.

    jeudi 27 février 2014 13:34
  • Bonjour,

    Plusieurs hypothèses peuvent justifier d'un tel comportement...

    Du fait que vous soyez la personne qui reprenne le développement de cette application, il est fort probable que vous ne connaissiez pas tous les tenants et aboutissants qui la constituent.

    En d'autres termes, dans un premier temps je vous préconiserais volontiers de rapatrier les deux fichiers en local et de travailler dans un répertoire de développement spécifiquement dédié à cet effet car il est probable que ce soit dû à des problèmes de droits sur le dossier réseau.

    Une fois cela fait, vous procédez au rattachement des tables de manière à ce que l'application frontale pointe vers la base de données dorsale sur l'ensemble des tables. 

    Lorsque cela est opérationnel, il est fort probable que la conception de cette application est été effectuée par quelqu'un qui ne maîtrisait pas par exemple le mode d'ouverture des jeux d'enregistrement ou encore les interactions qui peuvent agir et survenir entre deux tables ayant des relations.

    De ce fait, je vous proposerais volontiers de d'ouvrir tous les formulaires liés à une requête en mode création afin de vérifier le mode d'ouverture, les requêtes en elle-même, mais également les instructions VBA qui sollicitent le type de Recordset associé au formulaire, celui-ci pouvant avoir des incidences sur le comportement global de l'application.

    Il se peut aussi que au sein du code VBA du projet existent des appels d'instances qui ouvrent en mode exclusif par exemple la base de données dorsale et donc provoque bien entendu un échec lorsque vous tentez de modifier tel ou tel objet.

    Là, il vous faut regarder du côté des mots clé comme OpenDatabase...

    Enfin et surtout, je vous propose d'insérer dans les procédures et fonctions, de gestions d'erreur musclées associées à la possibilité de stopper le code en cas d'erreur grâce à l'instruction Stop couplée à l'instruction Resume qui vous permettra de reprendre la main et de comprendre l'éventuelle erreur et sa cause. Pour ce faire, vous pouvez user d'une constante publique qui vous permettrait de passer du mode débogage au mode mis en Prod de par la simple valeur True ou False.

    Exemple :

    Public Const MODE_DEBOGAGE = True
    
    Public Sub UneProcedure()
    
        On Error Goto UneProcedureErr
        [...]
    UneProcedureSortie:
        Exit Sub
    UneProcedureErr:
        If MODE_DEBOGAGE  Then
            Stop
            MsgBox Err.Description, , Err.Number
            Resume
        Else
            Resume UneProcedureSortie
        End If
    En Sub

    Une fois localisé votre problème, vous mettez en oeuvre une procédure de rattachement automatique des tables.


    Argy


    mercredi 5 mars 2014 09:54
    Modérateur
  • Merci pour vos précieux conseils.

    J'avais déjà fait une bonne partie de vos suggestions : rapatrier les deux fichiers localement dans un même dossier et attacher les tables de ce dossier à la base de données frontale.

    En fait, je suis travailleur autonome tout comme la personne qui avait débuté le développement de l'application et sommes situés à plus de 100 km l'un de l'autre. Donc, aucun lien n'existe entre nos ordinateurs. J'ai moi-même télécharger les fichiers de l'application.

    C'est un fait que je ne connaissais pas toutes les méthodes utilisées à l'origine pour contrôler l'application. Par exemple, aucun code VBA n'était utilisé, le développeur d'origine ne connaissant pas ce langage. Il utilisait plutôt des macros. Personnellement je n'utilise jamais de macros sauf pour la macro Autoexec qui ne fait qu'activer une fonction de démarrage de l'application en code VBA. J'ai d'ailleurs eu certaines difficultés à me défaire de toutes les macros existantes.

    Donc, aucune commande VBA d'ouverture de jeu d'enregistrements n'existait. Le développeur utilisait plutôt des requêtes prédéfinies. Encore une fois, je n'utilise que peu de requêtes prédéfinies sauf dans certains cas très spécifiques. Je préfère créer les requêtes au fur et à mesure à l'aide de code VBA. Je sais que ce type de requête peut exiger un certain délai de compilation lors de leur utilisation mais je n'ai jamais observé de problème criant lors de leur utilisation. De plus, ce mode de fonctionnement me permet de paramétrer les requêtes beaucoup plus facilement. D'autre part, les utilisateurs ne peuvent supprimer accidentellement mes requêtes puisqu'elles lui sont invisibles.

    J'utilise une procédure de gestion des erreurs centralisée dans toutes mes procédures, même si elles ne comportent qu'une seule ligne de code VBA. Les erreurs connues sont donc gérées efficacement. Lorsqu'une erreur inattendue est provoquée (ce qui risque d'arriver durant la période de rodage), un message s'affiche indiquant le numéro de l'erreur et la procédure ayant provoqué l'erreur.

    Au départ j'ai dû modifier la structure de toutes les tables existantes en supprimant les relations et les clés primaires d'abord. J'ai ensuite créer de nouveaux champs, de nouvelles clés primaires et de nouvelles relations. En fait, la structure existante causait un problème majeur que le développeur d'origine n'arrivait pas à surmonter. C'est à la suite de ce problème qu'on m'a confié le développement du logiciel.

    Il me reste donc à vérifier les formulaires existants au moment du rapatriement de l'application. Comme mentionné précédemment, en supprimant toutes les requêtes et en modifiant la structure des tables, j'ai aussi dû modifier la source des enregistrements des formulaires et en changer la structure dans une certaine mesure.

    Vos commentaires me mènent donc sur cette piste que je vais étudier attentivement.

    Je vous remercie pour votre intérêt et l'aide apportée.

    Claude Dionne

    mercredi 5 mars 2014 14:37