Précédent   Forum des professionnels en informatique > Bases de données > Firebird > Débuter
Débuter Forum d'entraide pour débuter avec Firebird
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 24/06/2004, 15h31   #1
Membre actif
 
Inscription : juin 2002
Messages : 379
Détails du profil
Informations forums :
Inscription : juin 2002
Messages : 379
Points : 168
Points : 168
Par défaut [TRANSACTION] Comment ca marche ???

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 :
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 est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 24/06/2004, 15h39   #2
Membre actif
 
Inscription : juin 2002
Messages : 379
Détails du profil
Informations forums :
Inscription : juin 2002
Messages : 379
Points : 168
Points : 168
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
kase74 est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 24/06/2004, 17h46   #3
Membre Expert
 
Avatar de Barbibulle
 
Frédéric
Inscription : octobre 2002
Messages : 1 722
Détails du profil
Informations personnelles :
Nom : Frédéric
Âge : 42

Informations forums :
Inscription : octobre 2002
Messages : 1 722
Points : 2 025
Points : 2 025
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.
Barbibulle est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 25/06/2004, 10h29   #4
Membre actif
 
Inscription : juin 2002
Messages : 379
Détails du profil
Informations forums :
Inscription : juin 2002
Messages : 379
Points : 168
Points : 168
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 :
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 !!!!!!
kase74 est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 25/06/2004, 15h14   #5
Membre Expert
 
Avatar de Barbibulle
 
Frédéric
Inscription : octobre 2002
Messages : 1 722
Détails du profil
Informations personnelles :
Nom : Frédéric
Âge : 42

Informations forums :
Inscription : octobre 2002
Messages : 1 722
Points : 2 025
Points : 2 025
Citation:
Envoyé par 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.
Non on ne peux pas pour les même raisons.
Citation:
Envoyé par kase74
(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.

Citation:
Envoyé par kase74
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 :
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...)
Barbibulle est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 28/06/2004, 15h00   #6
Membre actif
 
Inscription : juin 2002
Messages : 379
Détails du profil
Informations forums :
Inscription : juin 2002
Messages : 379
Points : 168
Points : 168
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 ?
kase74 est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 28/06/2004, 16h40   #7
Membre Expert
 
Avatar de Barbibulle
 
Frédéric
Inscription : octobre 2002
Messages : 1 722
Détails du profil
Informations personnelles :
Nom : Frédéric
Âge : 42

Informations forums :
Inscription : octobre 2002
Messages : 1 722
Points : 2 025
Points : 2 025
C'est le client qui décide de valider ou annuler la transaction.... Pas le serveur...
Barbibulle est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 02h47.


 
 
 
 
Partenaires

Hébergement Web