Discussion :

[Cl@udius]

Hello

Ayant installé récemment la dernière version de Firebird (2.5), je me suis naturellement intéressé au système de trace qu'offre celle-ci.

Je provoque malheureusement un crash du serveur lors de l'exécution de 2 requêtes consécutives au sein du même composant TUIBQuery.

Avec la base exemple EMPLOYEE, un test très simple sous Delphi:

Code Delphi :

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
19
20
procedure TFormTest.ButtonTestDynClick(Sender: TObject);
begin
  with TUIBQuery.Create(UIBTransaction1) do
  try
    SQL.Text := 'INSERT INTO COUNTRY (COUNTRY, CURRENCY) VALUES (?, ?);';
    Prepare;
    Close(etmCommit);
//  finally
//    Free;
//  end;
 
//  with TUIBQuery.Create(UIBTransaction1) do
//  try
    SQL.Text := 'UPDATE COUNTRY SET COUNTRY = ?, CURRENCY = ? WHERE COUNTRY = ?;';
    Prepare;
    Close(etmCommit);
  finally
    Free;
  end;
end;

L'exécution de ce code provoque ces erreurs:

Le projet ProjTest.exe a déclenché la classe d'exception EUIBError avec le message 'unknown ISC error 0
Error Code: 401'.

Puis, qui découle naturellement de la 1°:

Le projet ProjTest.exe a déclenché la classe d'exception EUIBError avec le message 'invalid statement handle
Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements
Error Code: 165'.

Firebird.log:

PORTABLEASUS (Client) Thu Nov 04 18:38:08 2010
INET/inet_error: read errno = 10054


PORTABLEASUS (Client) Thu Nov 04 18:38:08 2010
REMOTE INTERFACE/gds__detach: Unsuccesful detach from database.
Uncommitted work may have been lost

Bien entendu le Trace Log est interrompu sur le 2° prepare :

2010-11-04T18:38:05.3670 (3896:0120E01C) PREPARE_STATEMENT
EMPLOYEE (ATT_62, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
D:\Travaux\FirebirdBug\ProjTest.exe:4964
(TRA_698, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE)

Statement 77:
-------------------------------------------------------------------------------
UPDATE COUNTRY SET COUNTRY = ?, CURRENCY = ? WHERE COUNTRY = ?;

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (COUNTRY INDEX (RDB$PRIMARY1))
0 ms

Le fait de décommenter les lignes (donc un Free sur le composant puis recréation), ou d'arrêter le système de trace, ne pose plus de problème.

A votre avis: UIB ou Firebird en cause ?

@+ Claudius

[makowski]

A votre avis: UIB ou Firebird en cause ?

faire le test avec autre chose qu'UIB

ISQL ou Python par exemple ?

[Cl@udius]

faire le test avec autre chose qu'UIB

Dans ma démarche j'ai du mal à incriminer l'un ou l'autre que ce soit Firebird ou UIB.

ISQL ou Python par exemple ?

Je ferais une autre série de test demain. ISQL, j'aurais dû avoir ce réflexe.
Merci.

[makowski]

Question annexe, tu utilises bien la dernière version d'UIB ?

[Cl@udius]

Oui, la dernière révision du dépôt SVN.

[Cl@udius]

Bon je m'oriente vers un pb avec les composants UIB.

J'ai effectué, entre autre, un test avec les IBX (si si j'ai osé) et ça passe sans problème.

[Barbibulle]

Ah... faut que je garde mes IBX alors..

[makowski]

Bon je m'oriente vers un pb avec les composants UIB.

en fait il y avait un bug dans les UIB sur la réutilisation des requetes, mais normalement cela a été corrigé.

après peut être aussi que comme les prepare peuvent se faire hors transaction, tes enchainement

Code :

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

1
2
Prepare;
    Close(etmCommit);

ne sont pas terribles
il faut voir avec Henri et consorts

[Cl@udius]

en fait il y avait un bug dans les UIB sur la réutilisation des requetes, mais normalement cela a été corrigé.

Si tu fais référence à ce thread chez progdigy, oui je l'avais vu.

après peut être aussi que comme les prepare peuvent se faire hors transaction, tes enchainement

Code :

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

1
2
Prepare;
    Close(etmCommit);

ne sont pas terribles

Ca je te l'accorde ce n'est pas très orthodoxe, mais j'adore torturé mes compos favoris. A noter qu'avec des Open classiques, les symptômes sont les mêmes.

il faut voir avec Henri et consorts

Oui je verrais ça avec lui, mais en attendant j'essaye de cerner le problème plus finement. Histoire d'éviter de lui dire: Eh Henri, ça marche pas !

[Cl@udius]

Bon apparemment, un appel manquant à l'API isc_dsql_allocate_statement lors de l'ouverture du 2° query est à l'origine du problème (alors qu'un appel à isc_dsql_free_statement a précédé son ouverture).

Je vais essayé de soigner ma prose anglaise (), et remonter ça à Henri.

[makowski]

tu peux lui parler en français
ou poster en français sur nzn.fr.firebird

[Cl@udius]

Je n'avais pas relevé cette remarque en 1° lecture.

...comme les prepare peuvent se faire hors transaction, ...

L'appel à isc_dsl_prepare nécessite bien un Handle sur la transaction, non ?
Je ne saisis pas.

[makowski]

il peut être à NULL
http://tracker.firebirdsql.org/browse/CORE-1119