Discussion :

[Tchinkatchuk]

Bonjour à tous !

Je pense avoir bien compris le rpincipe des transactions. D'ailleurs cela march parfaitement dans mon script.

Mais j'aurais une question.

Les transactions font un ROLLBACK si il y a un probleme d'integrité des données, etc...

Mais si ma requete plante (un champs null qui ne doit pas l'etre par exemple), il continue et du coup modifie ce qui suit !
Est-il possible de dire qu'a la moindre erreur dans une requete SQL, il fait un Rollback ?

Merci d'avance et pardonnez moi, je debute en transactions

[Xo]

Tu es sous Oracle, je pense ?

Les erreurs en SQL n'étant pas "récupérées" par une gestion d'erreur, le ROLLBACK n'intervient pas dans ce cas, puisque rien n'est à valider pour l'instruction qui a renvoyé une erreur ?

En fait, choisir en fin de script SQL si l'on doit valider ou annuler le traitement de la transaction requiert une structure conditionnelle, qui n'est (à ma connaissance) pas gérable en SQL seul.

[Tchinkatchuk]

En fait, je suis sous postgreSQL et je developpe en php5.

Oui, je me doutais de ce que tu viens d'ecrire et malheureusement tu me confirme. Merci beaucoup.

Comme tu le dis, ca ne génère qu'une erreur SQL mais pas d'erreur pour les transactions. Il m'est donc impossible de savoir si tout s'est bien passé.

En ajoutant les transactions, j'evite les erreurs de serveur mais j'ajoute les erreurs de requete que je verifias avant mais que je ne peux plus faire a présent.

Fais ...

Si toutefois, quelqu'un connait une bidouille pour gerer cela, je lui paie un tonneau

[Tchinkatchuk]

Bon apparrement PEAR:B gère cela sans probleme.

J'utilise cette API depuis le debuit mais je n'avais aps fait attention à cette possibilité.

Merci beaucoup quand meme

[phili_b]

Je connais bien Oracle et pas du tout Postgres mais les exceptions sous Oracle sont très bien gerées:

Code :

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

1
2
3
4
5
6
7
BEGIN
        ... code here ...
EXCEPTION
        WHEN ... THEN
            ROLLBACK;
            ... code here ...
END;

En Pl/sql on peut récuperer les exceptions et les exceptions sont bien remontées dans les clients appelants (exemple dans Delphi avec try except end)

En utilisant la fonction recherche de http://www.postgresql.org avec le mot exception je tombe là dessus:
Example 35-7. Porting a Procedure from PL/SQL to PL/pgSQL

Exemple qui montre que Postgres a l'air bien de gérer les exceptions. Si le langage procédural (plpgsql semble-t-il) de postgres reconnait les exceptions, il n'y a pas de raison que les clients, et en particulier php, ne les gère pas.

Donc certes les exceptions ne se gèrent pas en SQL "pur" mais lors d'une erreur SQL la base de données envoit bien une exception gérable en l'occurence par php. (Ceci dans le cadre d'une transaction ou non).

[Tchinkatchuk]

Excellent !!

je te remercie beaucoup Philipp (je suppose que c'est ton nom lol).

Je vais tester ca des que possible. Ce serait le plus efficace et propre en effet.
Je ne pense jamais a ces exceptions !! Nickel

[Xo]

Les erreurs en SQL n'étant pas "récupérées" par une gestion d'erreur ...

Attention phili_b, je parlais bien de SQL, et non de PL/SQL !

[SQLpro]

Il n'existe aucune instruction SQL hormis l'exception de déférabilité qui induit un ROLLBACK.
Autrement dit, la gestion d'erreur n'a rien à voir avec la gestion des transactions. Et heureusement !

A +