Discussion :

[Invité]

Bonjour,

Comment récupère-t-on le N° de l'erreur SQL dans un except ?

Code :

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

1
2
on E : EDatabaseError do
     Showmessage('ERROR:'+ E.ClassName+ '-' +E.Message);

Les ClassName et Message, OK... mais par exemple, pour obtenir les error codes http://www.postgresql.org/docs/9.1/s...-appendix.html avec pqconnection, sqldb, db, comment procède-t-on (EDatabaseErrors have no ErrorCode...) ?

Merci. Cordialement. Gilles

[Ph. B.]

Bonjour,

Comment récupère-t-on le N° de l'erreur SQL dans un except ?

Juste avnt de répondre, j'ai vu que la question a été modifiée et faisait initialement référence à un message d'erreur de Firebird.
Dans ce cas, il faut utiliser l'exception héritée EIBDatabaseError et sa propriété GDSErrorCode

Pour Postgres, il n'y pas d'exception hérité de EDatabaseError, à moins de reprendre le code ou la fonction PQErrorMessage

[Invité]

Oui, bonsoir Philippe,

J'avais effectivement lu un Post concernant FireBird. Mais je travaille bien avec Postgresql 9.1.5...

J'étais en train de regarder si avec Zeos c'était jouable. PQErrorMessage ? Je suis remonté jusque là... Bon on va laisser passer la nuit.

[Invité]

Donc il semble qu'il faille aller dans les composants... Hum, je donne déjà suffisamment.

Pour Firebird, je suppose qu'il est mieux intégré dans Lazarus (voire Delphi) puisqu'il s'agit d'un clone d'Interbase de Borland. Mais ce n'est qu'une supposition pour Delphi. Avec ce dernier, j'en étais resté au fait que les composants dédiés InterBase de Delphi n'étaient plus vraiment compatibles avec FireBird... pas nécessairement d'ailleurs du fait de Borland mais également du clone qui s'écartait progressivement d'IB.

Bref, j'ai hésité au moment de remplacer mySQL. Là encore, j'ai peiné à obtenir de l'information correcte.

Donc j'ai choisi d'essayer par moi-même. J'ai commencé par PostgreSQL et je pense que je vais le conserver... même si là, je sens que mon programme va se compliquer d'un coup alors que j'ai tout fait pour utiliser les méthodes standards (et prévues)... C'est le premier "manque" que je rencontre avec PostgreSQL qui jusqu'à présent m'avait permis de respecter une approche plus conventionnelle que celle que je pratique habituellement. Mais je suppose que j'aurais été tout aussi satisfait par Firebird si j'avais commencé par lui. Enfin pour être honnête, j'avais fait un test il y a quelques années et j'avais eu... disons du mal à m'adapter.

Finalement avec "mon" PostgreSQL, pour l'instant je ne vois que 2 approches possibles

• soit émettre des requêtes supplémentaires une fois l'exception déclenchée
• soit analyser les E.messages.

Les requêtes supplémentaires, c'est envisageable mais lourd et l'analyse des E.message pose un petit problème. Le E.message est multilingue :

pqConnection1 : Execution of query failed (PostgreSQL: ERREUR: la valeur d'une clé dupliquée rompt la contrainte unique .... DETAIL: La clé .... existe déjà.)

Par exemple, l'analyse de l'erreur reposerait sur la détection de la séquence [clé... existe déjà ou rompt... contrainte unique].

Peut-on supposer que la première partie (en anglais) vienne de Lazarus et que l'autre (en français) soit le retour du serveur PostgreSQL ? "Y a qu'à aller voir dans les codes".... ou expérimenter : mes 2 serveurs Debian ont été installés en Français. Donc, je n'ai pas ce moyen... et je n'ai pas trop le temps d'aller visiter les codes en ce moment.

Mais si la deuxième partie du message arrive en anglais (parce que je déplace ma base sur un serveur dont Linux a été installé en anglais), la détection des mots clés français est HS...

------------------------------------------

22H50 : Compte-tenu du temps "un peu" pluvieux en Normandie toute la journée , j'ai regardé le pqconnection.pp. La première partie du E.message vient bien de son code. On y trouve:

Code :

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

1
2
3
4
5
6
7
8
9
10
ResourceString
  SErrRollbackFailed = 'Rollback transaction failed';
  SErrCommitFailed = 'Commit transaction failed';
  SErrConnectionFailed = 'Connection to database failed';
  SErrTransactionFailed = 'Start of transacion failed';
  SErrClearSelection = 'Clear of selection failed';
  SErrExecuteFailed = 'Execution of query failed';
  SErrFieldDefsFailed = 'Can not extract field information from query';
  SErrFetchFailed = 'Fetch of data failed';
  SErrPrepareFailed = 'Preparation of query failed.';

Et la seconde vient bien de PostgreSQL et dépend en effet de la localisation (ie de la langue du serveur).

Il est préférable que les applications qui souhaitent connaître la condition d'erreur survenue testent le code d'erreur plutôt que d'effectuer une recherche dans le message d'erreur textuel. Les codes d'erreurs sont moins sujets à changement au fil des versions de PostgreSQL™ et ne sont pas dépendants de la localisation des messages d'erreur.

Mais, il y a un espoir. D'après ce que je vois, le problème a été plus que partiellement résolu. http://mantis.freepascal.org/bug_vie...p?bug_id=22336. La piste n'a pas été finalisée semble-t-il, en tout cas pas intégrée dans la version dont je dispose ici, 1.1-38618 fpc-2.6.1-20120912. Je vais installer la dernière trunk... Il est peut-être dedans.

Cordialement. Gilles

[Invité]

En effet, le patch est intégré à la Lazarus-1.1-38979-fpc-2.6.1-20121007-winXX.exe pour les Windowsiens ou/et pour les autres à la http://svn.freepascal.org/svn/fpc/trunk.

J'ai donc installé une version dotée de ce patch. Il fonctionne dans certaines circonstances et pas dans d'autres ?!

[Invité]

Le problème a été réglé dans la dernière fpc/trunk 2.7.1-Rev. 22610. On récupère désormais le Code Error des TPQConnection...

Merci à Ludob.

Cordialement. Gilles