Gestion des verrous VBA + Base Access

Gestion des verrous VBA + Base Access - VB/VBA/VBS - Programmation

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
Reply

Marsh Posté le 01-12-2016 à 18:25:34   

Reply

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 …
 

Reply

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

Message cité 1 fois
Message édité par edma le 02-12-2016 à 00:17:14
Reply

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.

Reply

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.
 
Err.Number est accessible à tout moment. Il est juste nul tant qu'il n'y a pas 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
 

Reply

Marsh Posté le 03-12-2016 à 18:14:44    

edma a écrit :


 
Tout à fait d'accord.  
 
Ma question n'est pas tant de préciser le rôle du On error ...
 


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.
 

Reply

Marsh Posté le 04-12-2016 à 10:46:37    

benriach a écrit :


certes, mais tu as bien écrit


 

benriach a écrit :


D'où le sens de mon intervention.
 


 
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.  

Reply

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/


---------------
Du tofu en Alsace : www.tofuhong.com
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed