Discussion :

[niko8181]

Bonjour,
Depuis que nous avons migré une base qui était en ACCESS 97 vers ACCESS 2000, nous obtenons le message suivant lorsqu'on veut enregistrer des modifs faites dans le code VBA :
"Vous n'avez pas l'accès en mode exclusif à cette base de données pour le moment. Les modifications apportées à la structure ne seront pas enregistrées."

Effectivement, il y a en permanence plusieurs personnes de connectées sur cette base de données.

Est-ce normal / y-a-t-il un moyen de contourner ?


Merci pour votre aide,

[Merryvor]

Bonjour,

Tant que quelqu'un utilise la base, il n'est pas possible de modifier le code VBA, et c'est logique. Il faut modifier en dehors des horaires de consultations, ou demander que personne n'utilise la base de telle heure à telle heure.

[niko8181]

Je ne trouve pas cela si logique puisque l'on peut très bien modifier des requêtes, ou des tables si personne n'est dessus.

Donc il me semblerait logique de pouvoir modifier du code VBA "inerte", dans le sens qu'il n'est lié à aucun formulaire mais utilisé pour la MAJ nocturne des données de la base.

De plus ACCESS 97 autorisait ce type de modif...

çà me semble être une régression vraiment pénalisante entre ces 2 versions.

[Invité]

Bonjour

Excuses moi, mais il est aberrant de modifier du code sur une base en cours de fonctionnement.

Il faut le faire sur une autre et ensuite un remplacement (dans la mesure ou tu es dans un schéma Forntale/Dorsale).

Philippe

[niko8181]

Cela ne me semble pas si aberrant pour un outil relativement souple comme access.
Mon problème c'est qu'il y a des gens connectés en permanence de 07h30 à 19h00 voire plus, ce qui rend compliquée toute intervention sur la base (dorsale).

[LeonNatage]

Si tu veux modifier le code de ta dorsale, le mieux c'est tu la copie, tu la modifie, tu la teste. Et le matin tu arrives à 7h et tu la copie à la place de l'autre. Personnellement je ne code jamais sur une dorsale donc je peux pas te dire si c'est bien ou pas.

[Psychopathe]

Cela ne me semble pas si aberrant pour un outil relativement souple comme access.
Mon problème c'est qu'il y a des gens connectés en permanence de 07h30 à 19h00 voire plus, ce qui rend compliquée toute intervention sur la base (dorsale).

Désolé d'en rajouter mais pourquoi modifier un code quand des utilisateurs sont en train de l'utiliser? Imaginons que tu modifie le code qui effectuait un calcul par exemple, ben le résultat risque de changer, et les répercussions peuvent être sévères. D'un point de vue de sécurité, c'est donc assez dangereux. N'oublie pas aussi la notion de "compilation".
Modifier un code alors que l'application est livrée, cela suppose que ton application est encore incomplète. La question est plutôt de savoir ce qui te pousse à changer ton code sans arrêt.
La meilleure et seule solution qui te reste de partir plus tard ou d'arriver plus tôt que les utilisateurs afin de procéder aux modifications. Voire de connaitre les gens utilisant la base en temps réel et de demander à ces personnes de fermer la base le temps de faire tes modifications.

[jojo5650]

Mais j'y ai remédier
Scinder les données et l'interface graphique qui contient toutes les requetes modules états et macros.
Dans l'interface graphique toutes les tables de données sont liées.

Ajouter sur les 2 projets une table version avec un champs date de chaque coté. Faites une fonction qui teste l'egalité de ces même date et vous l'exécutez au démarrage.
Si elle répond true alors on continue , sinon sortie affichage "mauvaise version veuillez télécharger la bonne version"
Si oui alors on teste ensuite, dans cette même fonction le path de cette application avec celui qui correspond à l'emplacement physique du réseau où vous déposer votre interface graphique.

Si il y égalité entre le path et la variable du code vba et de l'appli alors refus de travailler; ainsi cela obligera tous les utilisateurs à copier ce projet sur son pc ou ailleurs donc affichage "mauvaise version veuillez télécharger la bonne version".

Vous pouvez aussi ajouter cela la sécurisation du réseau par l'intermédiaire de l'NTFS.

Voilà pour l'usage. il suffit de dire aux utilisateurs qu'ils doivent copier le projet où bon leur semble pour l'utilisé.

Pour le dévellopeur, il modifie sur son pc l'application, quand il estime son projet UpToDate il prend soin de mettre à jour la table version sur le serveur de data et sur sa nouvelles DB Interface graphique.
Il pose cette nouvelle interface graphique sur le réseau. Résultat
Les utilsateurs qui utiliserons leur projet personnel, donc non encore modifié , ne fonctionnerons plus puisque la date de la version ne sera plus identique à celle du serveur de data donc sortie. Seuls ceux connectés au moment du transfert pourrons encore continer.
C'est assez abstrait mais c'est ce que j'utilise comme procédé.

L'avantage aussi vous n'avez qu'une seule et unique personne sur son interface graphique. Vous ne devez pas vous occuper de savoir qui est connecté pour lui demandé de sortir de l'appli
.
De plus quand l'application (cela arrive) se plante chez un utilisateur c'est seulement lui qui est embété pas les autres. Il doit juste técharger l'application sur le réseau et recommencer.

Désolé d'en rajouter mais pourquoi modifier un code quand des utilisateurs sont en train de l'utiliser? Imaginons que tu modifie le code qui effectuait un calcul par exemple, ben le résultat risque de changer, et les répercussions peuvent être sévères. D'un point de vue de sécurité, c'est donc assez dangereux. N'oublie pas aussi la notion de "compilation".
Modifier un code alors que l'application est livrée, cela suppose que ton application est encore incomplète. La question est plutôt de savoir ce qui te pousse à changer ton code sans arrêt.
La meilleure et seule solution qui te reste de partir plus tard ou d'arriver plus tôt que les utilisateurs afin de procéder aux modifications. Voire de connaitre les gens utilisant la base en temps réel et de demander à ces personnes de fermer la base le temps de faire tes modifications.