Problème Syntaxe COMMIT

[merive]

Quelqu'un saurait-il m'aider à comprendre pourquoi les 2 lignes suivantes ne se compile pas dans "IBExpert" en tant que procédure stockée (pour une base de données Firebird 1.5)

Code :

1
2
UPDATE CLIENTS SET codemagasin=0; /* 0 pour l'exemple */
commit;

sachant que avant de mettre "commit" ça se compile tout à fait bien et fonctionne sauf que ça provoque des "deadlock"
et en ajoutant le commit j'obtiens une "parsing error" au cours de la compil par IBExpert...
merci

[makowski]

déjà au sein d'une procédure stockée on ne peut utiliser de COMMIT
des points de sauvegarde oui, mais pas des commit

[merive]

Aïe ... comme mon client est un éxecutable et que la seule manière que j'ai d'agir (modifier) sur les données est l'utilisation d'états (je crée des états avec fastreport), j'utilise les procédures stockées ... n'ai-je donc aucun moyen pour "committer" mes changements ?

[makowski]

ben si
le commit a lieu après l'execution de la procedure

Code :

1
2
EXECUTE PROCEDURE BLA;
COMMIT;

[merive]

oui mais dans mon cas, l'appel de la procédure se fait par un objet "requête IBX" de Fastreport ; serait-ce là que le code que vous proposez devrait se trouver ?

[merive]

et j'ai oublié de préciser, avec FastReport, les objets IBX sont limités à TfrBDEQuery pour faire des SQL search (select ...) ; c'est pour cela que je pense que je ne pourrai pas y faire un execute + commit ... et que j'aurais voulu inclure le commit dans la procedure que j'appelle par le Select.

[makowski]

il suffit de faire le commit après le select sur la transaction liée à l'objet qui fait le select

[merive]

Il me semble que l'objet utilisé pour le search ne permet pas d'enchainer les lignes : en effet voici la ligne que j'ai dans le texte SQL de mon objet Query8

Code :

SELECT VAL_FIDEL  FROM etat_remise_fid(5,2,:notiers)

et qui me donne accès ensuite à : [DialogForm.Query8."VAL_FIDEL"]

En rajoutant commit l'objet ne renvoie plus rien ...
et j'ai également essayé avec

Code :

1
2
3
4
begin 
 SELECT ... ;
 commit;
end

L'objet ne "répond plus" ...

[makowski]

il y a bien un objet quelquonque qui gère la transaction, genre TIBTransaction
c'est sur lui qu'il faut appliquer le commit

[merive]

Sans doute mais je pense que je n'ai pas accès à ce code ; comme je disais mon client est un executable et les seules évolutions que je peux apporter passent par un éditeur d'état (FastReport) avec ses objets (par ex le TfrBDEQuery pour le search) mais ensuite je n'ai plus le contrôle ...
Ce que je vais faire pour avancer c'est d'autres tests parce que j'ai noté que la configuration où les deadlocks se produisent est une configuation avec Firebird 151 (et c'est cette configuration qui est en exploitation) et j'ai une autre configuration similaire pour mes essais mais elle fonctionne avec Firebird 153 et là le problème des deadlock ne se produit pas. Je vais commencer par clarifier ça.
EN tous cas, merci pour les conseils apportés jusque là. On peut peut-être fermer cette discussion et si j'ai plus d'éléments après les vérifications que je me propose de faire, je rouvrirai un sujet.
ENcore merci.

[Barbibulle]

Code :

UPDATE CLIENTS SET codemagasin=0;

Met a jour tous les clients, c'est le genre de traitement qui forcément tres risqué en terme de deadlock... Et si elle fonctionne va bloquer (deadlock) tous les autres traitements qui souhaiteraient modifier un client. Donc a éviter mais s'il n'y a pas d'autres solution, c'est en tous les cas à commiter au plus vite. Dans une transaction la plus courte possible.

Ce n'est pas le genre de chose qu'on va mettre dans la meme transaction qu'un traitement d'édition qui peut durer longtemps.

Pour situer un peu mieux le probleme évoqué :

Concernant les transactions ca peux englober tout un tas de traitement, des selects, updates, appel de PS (qui elles meme font des mises à jours etc.) et donc il est normal que ce soit le client qui lance toute ces opérations qui au final puisse dire s'il valide tout ca ou non (commit ou rollback.).

Imaginez que votre PS puisse commiter la transaction. Comment pourait elle prendre la bonne décision puisqu'elle n a pas connaissance des traitements fait avant son lancement et ceux apres.

[edam]

Envoyé par Barbibulle

Pour situer un peu mieux le probleme évoqué :

Concernant les transactions ca peux englober tout un tas de traitement, des selects, updates, appel de PS (qui elles meme font des mises à jours etc.) et donc il est normal que ce soit le client qui lance toute ces opérations qui au final puisse dire s'il valide tout ca ou non (commit ou rollback.).

Imaginez que votre PS puisse commiter la transaction. Comment pourait elle prendre la bonne décision puisqu'elle n a pas connaissance des traitements fait avant son lancement et ceux apres.

tu peut expliqué plus svp