Discussion :

[kase74]

Bonjour,
J'ai beau lire, et relire tout ce que je trouve sur le sujet, mais je n'y arrive pas !!!

Je travail avec Firebird 1.5, je voulais ecrire le trigger suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
...
BEGIN TRANSACTION MAJ_ARTICLE
   UPDATE ARTICLE A
   SET A.QTE = A.QTE - VariableB
   WHERE A.CODE_ARTICLE = VariableA;
COMMIT TRANSACTION MAJ_ARTICLE;
...

[kase74]

D'ailleur, sur le meme sujet, j'ai une autre question :
- Par rapport au niveau d'isolation, comment connaitre celui qui est effectif, et comment le modifier pour le mettre en SERIALIZABLE

[Barbibulle]

On ne peux débuter une transaction dans un trigger.

Le trigger est déclanché par rapport à un évènement sur une table (Update, insert ou delete).
Donc par rapport à un ordre SQL (qu'il soit dans une PS ou depuis le client c'est la même chose).

Au bout de la chaine on a le client qui a lancé cet ordre SQL ou PS. Et c'est ce client qui crée la transaction et qui la ferme.

Il n'y a pas d'imbrication de transaction. Il peux y avoir plusieures transactions mais elles ne sont pas imbriquées.

Sous FB il y a une nouveauté c'est la possibilité au sain d'une transaction de poser des "savepoints" de continuer le traitement (toujours dans la même transaction sans que celle ci ne soit encore validée ou annulée) et de pouvoir annuler les traitements fait depuis ce savepoint sans a avoir annuler toute la transaction.

[kase74]

Bonjour,
OK, j'ai compris pourquoi les transactions ne peuvent pas etre placee dans un trigger, alors je vais la mettre dans une procedure stockee.
(cf l'excellent site (en francais) que je recommande a tous : SQLPRO qui passe en revue le langage, le moyen de le mettre en oeuvre et ses faiblesses. http://sqlpro.developpez.com/TECH/SQL_TEHC.html)

Bon, soit ! Mais j'ai vu dans le release de Firebird, il existait l'option WITH LOCK.

Je veux qu'en inserant un article dans la table COMMANDE, automatiquement un trigger verifie dans la table ARTICLE sa disponibilite, et decremente sa quantite restante a disposition.
Est ce que cette option m'assure que je n'aurait pas de probleme lors de mise a jour de donnees en concurrence ?
Ce qui donnerait le trigger suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
... 
   UPDATE ARTICLE A 
   SET A.QTE = A.QTE - VariableB 
   WHERE A.CODE_ARTICLE = VariableA
   WITH LOCK; 
...

Pourquoi un trigger ? Parceque je veux
- que cette operation se fasse sur le serveur, pour respecter les recommandations judicieuses de Frederic BROUARD a ce sujet (cf le site)
- et tout simplement pour eviter de creer une multitude de procedures stockees, qui si je ne m'abbuse doit correspondre a une pour chaque operation UPDATE que j'ai a faire sur mes tables.

Barbibulle, merci d'etre toujours present !
LONGUE VIE A BARBIBULLE !!!!!!

[Barbibulle]

Bonjour,
OK, j'ai compris pourquoi les transactions ne peuvent pas etre placee dans un trigger, alors je vais la mettre dans une procedure stockee.

Non on ne peux pas pour les même raisons.

(cf l'excellent site (en francais) que je recommande a tous : SQLPRO qui passe en revue le langage, le moyen de le mettre en oeuvre et ses faiblesses. http://sqlpro.developpez.com/TECH/SQL_TEHC.html)

Bon, soit ! Mais j'ai vu dans le release de Firebird, il existait l'option WITH LOCK.

Je vous le déconseil, car dans la plupart des traitements c'est inutile.
Et c'est justement la grosse différence entre Oracle et Interbase. Oracle utilise des verrous ce qui peux poser de gros problemes de maintenance. Car si le traitement plante, le verrou lui reste et il faut appeler le DBA pour qu'il l'enlève manuellement...
Interbase fonctionne sans verrous, il "versionnise" les enregistrements. Ce qui est un gros avantage, car ne bloque pas les autres traitements.

Je veux qu'en inserant un article dans la table COMMANDE, automatiquement un trigger verifie dans la table ARTICLE sa disponibilite, et decremente sa quantite restante a disposition.
Est ce que cette option m'assure que je n'aurait pas de probleme lors de mise a jour de donnees en concurrence ?
Ce qui donnerait le trigger suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
... 
   UPDATE ARTICLE A 
   SET A.QTE = A.QTE - VariableB 
   WHERE A.CODE_ARTICLE = VariableA
   WITH LOCK; 
...

Pourquoi un trigger ? Parceque je veux
- que cette operation se fasse sur le serveur, pour respecter les recommandations judicieuses de Frederic BROUARD a ce sujet (cf le site)
- et tout simplement pour eviter de creer une multitude de procedures stockees, qui si je ne m'abbuse doit correspondre a une pour chaque operation UPDATE que j'ai a faire sur mes tables.

En plus là votre verrou est posé trop tard, car en cas d'accés concurrent, entre votre select pour vérifier la quantité et votre update un autre traitement à pu mettre à jour la quantité. Et donc lors de votre update, interbase génèrera une erreur de mise à jour, vous informant que quelqu un d'autre à déjà mis à jour la quantité (en fait lors de votre update, il s'appercoit que la version de l'enregistrement que vous voulez mettre à jours n'est pas la dernière...)

[kase74]

Ah bon, on ne peut pas non plus dans une procedure stockee !!!
Bon, mais alors j'ai pas tout compris au site de F. Brouard.

Mais alors il n'est pas possible de mettre la transaction sur le serveur ???

Ou est la solution ?

[Barbibulle]

C'est le client qui décide de valider ou annuler la transaction.... Pas le serveur...