Discussion :

[freud]

Bonsoir à tous,

Deux utilisateurs accèdent au même enregistrement. Le 1er supprime l’enregistrement le 2eme le vois toujours et pourrait l'editer et poster les modifications. Donc pour l’en empêcher puisque la ligne n’existe plus, j’essaye de faire un teste d’existence dans un Trigger update :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
CREATE OR ALTER TRIGGER TEST_BU0 FOR TEST
ACTIVE BEFORE UPDATE POSITION 0
AS
DECLARE VARIABLE RES INTEGER;
DECLARE VARIABLE MES VARCHAR(100);
BEGIN
 IF (COALESCE(NEW.ID,0)<>0) THEN
 BEGIN
 SELECT 1 FROM TEST WHERE ID=NEW.ID INTO :RES;
 RES=COALESCE(:RES,0);
  IF (:RES=0) THEN
  BEGIN
  MES ='L''ENREGISTREMENT A ETE SUPPRIMER';
  EXCEPTION NOT_FOUND  MES;
  END
 END
END

Cette méthode ne fonctionne pas et j’ai du dépanner avec un SELECT avant de faire l’UPDATE depuis le client pour tester l’existence de la ligne en attendant de trouver une solution qui pourrait s’appliquer dans un trigger. Pourriez-vous SVP m’eclairer ?
Merci

[escartefigue]

Ce problème est lié à une mauvaise gestion de l'isolation et du verrouillage l'ajout d'un trigger n'est pas la solution.

[freud]

Bonjour,

Oui mais lorsque l'enregistrement supprimé n'est pas tout de suite editer par le 2eme mais il pourrait le voir puisqu'il est déjà positionné dessus (dans une grid) il aurait suffit d'un simple rafraîchissement pour que la ligne disparaissent avant l'edition mais ne peut le faire dans ce contexte. Pour le niveau d'isolation j'utilise les paramètres suivant dans une transaction en ecriture:

Code :

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

1
2
 
tpConcurrency, tpWait,tpWrite

[freud]

Ce problème est lié à une mauvaise gestion de l'isolation

Je formulerais ma question autrement.
Quand on fait un UPDATE d'un enregistrement qui n'existe plus dans la BDD le serveur devrait renvoyer ce type de message:

Code :

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

1
2
3
 
 Statement failed, SQLCODE = -901 
 cannot update erased record

Il faudrait utiliser quel niveau d'isolation pour obtenir ce type de message ?
Merci.

[escartefigue]

Ne souhaitez vous pas éviter la mise à jour d'une ligne qui n'existe plus, plutôt que de générer un message d'erreur.
Une isolation CS voire RR permet d'éviter le phénomène

[freud]

Ne souhaitez vous pas éviter la mise à jour d'une ligne qui n'existe plus, plutôt que de générer un message d'erreur.

Certainement, si vous faite allusion à la méthode que j'utilise en ce moment, le SELECT avant l'UPDATE mais elle me semble un peu lourd depuis le client car je dois démarrer 2 transactions :

-SELECT/COMMIT

et si teste OK

-UPDATE/COMMIT

voire RR permet d'éviter le phénomène

Désolé, je n'ai pas compris RR

Merci.

[escartefigue]

RR comme Repeatable Read pardon

Cf. https://www.firebirdsql.org/pdfmanua...nsactions.html

[freud]

Je me suis compliquer la chose.
Franchement la méthode utilisé était bourrin fallait simplement tester le RowAffected depuis le client et c'est tout

[SQLpro]

En plus d'être lourde, cette méthode ne garantit pas tous les cas de figure... En effet, l'ajout d'une ligne n'est pas concerné par les verrous du niveau d'isolation REPEATABLE READ .

Mais je ne voit strictement aucun intérêt à faire ceci en 2 requêtes. Une seule suffit : envoyer l'UPDATE puis s'interroger sur le nombre de ligne mis à jour.

A +

[Artemus24]

Salut à tous.

Un peu de lecture :

http://www.firebirdsql.org/manual/is...nsactions.html

http://www.firebirdsql.org/refdocs/l...set-trans.html

https://www.ibphoenix.com/resources/...how_to/doc_400

http://ibexpert.net/ibe/index.php?n=...tionsExplained

@+

[freud]

Bonjour tout le monde,

Artemus24, merci pour les liens