Gestion des verrous VBA + Base Access - VB/VBA/VBS - Programmation
Marsh Posté le 01-12-2016 à 19:43:39
Bonjour,
déjà en désactivant l'instruction On Error Resume Next ou aux endroits stratégiques tester Err.Number
les codes d'erreur seront alors bien visibles …
Marsh Posté le 02-12-2016 à 00:14:17
Sauf si je me trompe, mais On Error Resume Next permet de récupérer les codes ERR.Num et ERR.description, de les tester et de les gérer juste après l'instruction qui "plante"
Le pb c'est que :
1 - je ne suis pas place pour analyser ce conflit d'accès qui ne se produit qu'une fois ou deux par semaine.
2 - j'ai tenté de reproduire sans succès l'incident sur un seul poste, chez moi, en lançant d'une part le logiciel et en attaquant d'autre part la base de données directement par MS-Access, le logiciel ne plante jamais en erreur, sans doute parce que je ne sais pas verrouillé un enregistrement directement à partir d'ACCESS
Marsh Posté le 02-12-2016 à 17:10:30
"On Error Resume Next" permet à la procédure/fonction de ne pas s'interrompre en cas d'erreur.
Err.Number est accessible à tout moment. Il est juste nul tant qu'il n'y a pas d'erreur.
Marsh Posté le 03-12-2016 à 11:20:31
benriach a écrit : "On Error Resume Next" permet à la procédure/fonction de ne pas s'interrompre en cas d'erreur. |
Tout à fait d'accord.
Ma question n'est pas tant de préciser le rôle du On error ...
Mais de savoir dans un environnement multi-utilisateur comment se comporte la séquence d'instructions suivante :
req = "SELECT Status, Verrou FROM Parametres"
On Error Resume Next ' (ou pas )
Matable.CursorLocation = adUseServer
Matable.Open req, ThisWorkbook.Db, adOpenKeyset, adLockPessimistic, -1
' et plus loin
Matable.Update
sachant qu'un autre utilisateur a lancé "juste avant" la même séquence depuis un autre PC et n'a pas encore exécuté le Update qui libérerait le verrou posté sur le serveur où se trouve la DB Access
Marsh Posté le 03-12-2016 à 18:14:44
edma a écrit : |
certes, mais tu as bien écrit
edma a écrit : Sauf si je me trompe, mais On Error Resume Next permet de récupérer les codes ERR.Num et ERR.description, de les tester et de les gérer juste après l'instruction qui "plante" |
D'où le sens de mon intervention.
Marsh Posté le 04-12-2016 à 10:46:37
benriach a écrit : |
benriach a écrit : |
OK, pigé le sens ! Le pb c'est que l'erreur "semble" ne jamais se produire même si le
l'enregistrement est verrouillé par ailleurs.
Marsh Posté le 08-12-2016 à 13:57:22
je suis tomber la dessus, peut être en exécutant tes requêtes différemment :
http://www.developpez.net/forums/d [...] onctionne/
Marsh Posté le 01-12-2016 à 18:25:34
Bonjour,
J'ai repris une application multi-utilisateurs en VBA EXCEL qui accède à une base ACESS sur un serveur.
Pour des raisons internes à l'application j'ai du sérialiser les transactions de mise à jour par les commandes begintrans, committrans.
De plus avant de lancer une transaction de mise à jour je dois accéder à une table (paramètres) contenant un enregistrement unique pour le mettre à jour.
j'accède à cet enregistrement comme suit (avant de le mettre à jour par un update -ou pas- selon les valeurs de Status et Verrou) :
req = "SELECT Status, Verrou FROM Parametres"
On Error Resume Next
Matable.CursorLocation = adUseServer
Matable.Open req, ThisWorkbook.Db, adOpenKeyset, adLockPessimistic, -1
.......
Matable.update
....
En général tout se passe bien sauf lorsqu'il y a conflit avec une même requête lancée par un autre utilisateur. je suis en vba et je n'ai pas de message d'alerte.
Ma question est double :
Comment tester que cet enregistrement n'est pas verrouillé ?
et sinon
Que se passe-t-il s'il est verrouillé ? plantage code erreur à tester ?
Merci de vos réponses
Message édité par edma le 01-12-2016 à 18:41:28