Discussion :

[cantador]

J'ai une installation classique :
Application client/serveur
serveur NT + postes clients
sur le serveur et les postes clients ->> version Firebird 1.5.4
les exécutables sur postes clients.
Le poste admin (le mien) est en client/serveur

Tout marche nickel et depuis longtemps et la base est entretenue régulièrement.

J'ai construit un autre petit outil en dehors de mon appli qui se connecte de la même manière qu'un poste client sur la même base que l'appli.
(une boucle sur une table qui lance des requêtes SQL (select sum()) et selon un test stocke des infos dans une ListBox. (une petite vérif de données..)
Evidemement, il y a bcp de requêtes..(mais aucun insert, ni update)

Lors du lancement à chaud de ce programme, tout se passe bien..
MAIS, à la fin, lorsque la boucle est terminée et que je clique sur le fermerture de la forme, le service FIREBIRD situé sur le serveur NT
SE PLANTE !

et bing, plus personne ne peut utiliser l'appli..
je suis obligé de le fermer (car on le voit actif sur le serveur) et le relancer et tout refonctionne nomalement.

J'ai lu avec attention toutes les questions relatives au plantage Firebird mais je n'ai pas trouvé d'explications satisfaisantes en ce qui concerne mon souci pour l'instant.

Si quelqu'un a une idée, car quelquefois comme vous le savez, il suffit d'un petit détail pour faire changer le cours des choses..

je vous en remercie par avance

[cantador]

Peut-être aurait t-il été judicieux de glisser ma question dans le forum
"Interbase et Firebird" ?

[qi130]

Peut-être aurait t-il été judicieux de glisser ma question dans le forum
"Interbase et Firebird" ?

Euh, non !

Il semble évident que c'est ton petit prog de contrôle qui est en cause.

Il serait donc judicieux d'étoffer le contexte (cf les Règles)
- version de Delphi
- quels composants pour accéder à la base
- chaine de connexion
- synoptique d'un traitement réalisé (code significatif à fournir)

pour commencer

[makowski]

et j'ajouterai aussi savoir comment sont gérées les transactions dans ce contexte

[cantador]

Tout d'abord, je vous remercie pour l'intérêt que vous portez à la question posée et je m'empresse de vous fournir le maximum d'élèments :

Les programmes sont écrits sous D7.
Les composants sont les TIBO qui se connectent directement à la base sans OBDC et plus précisemment le TIB_Connection et le TIB_transaction.

Dans l'application principal les transactions gérées par les méthodes StartTransaction, CommitRetaining, RollBackRetaining.

pour ce qui est de l'outil extérieur, je n'ai pas jugé utile de créer des transactions puisque je n'écris rien dans la base..

voici le code du prog externe :

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
 
procedure TForm1.JvSpeedButton1Click(Sender: TObject);
var
totalproductionbilan, totalproductionactivite: Currency;
NumAffaire: variant;
begin
try
NumAffaire := '';
screen.Cursor := CrHourGlass;
QDevis.First;
 
while not QDevis.Eof do
begin
with Qproduction.SQL do
begin
Qproduction.Close;
Clear;
Add('SELECT sum(DEVIS_SOUSTRAITANT.PRODUCTION) as CUMULPRODBILAN ');
Add('FROM DEVIS_SOUSTRAITANT ');
Add('WHERE CODEDEVIS =EV ');
Add('GROUP BY CODEDEVIS ');
Qproduction.ParamByName('DEV').Value := QDevisCODEDEVIS.Value;
Qproduction.Open;
if Qproduction.fieldByName('CUMULPRODBILAN').Value = Null then
totalproductionbilan := 0
else
totalproductionbilan := Qproduction.fieldByName('CUMULPRODBILAN').Value;
end;
with Qproduction.SQL do
begin
Qproduction.Close;
Clear;
Add('SELECT sum(PRODUCTION.STHTPRODUIT) AS CUMUMPRODACTIVITE ');
Add('FROM PRODUCTION ');
Add('WHERE CODEDEVIS =EV ');
Add('GROUP BY CODEDEVIS ');
Qproduction.ParamByName('DEV').Value := QDevisCODEDEVIS.Value;
Qproduction.Open;
if Qproduction.fieldByName('CUMUMPRODACTIVITE').Value = Null then
totalproductionactivite := 0
else
totalproductionactivite := Qproduction.fieldByName('CUMUMPRODACTIVITE').Value;
end;
 
if totalproductionbilan <> totalproductionactivite then
begin
NumAffaire := QAffaire.Lookup('CodeAffaire', QDevisCODEAFFAIRE.Value, 'NoAffaire');
if NumAffaire <> Null then
ListBox1.Items.Add(NumAffaire + ' ' + QDevisNODEVIS.Text + ' ' + IntToStr(QDevisCODEDEVIS.Value));
Application.ProcessMessages;
end;
QDevis.Next;
end;
finally
Screen.Cursor := CrDefault;
ShowMessage('terminé');
end;
end;
 
procedure TForm1.FormCreate(Sender: TObject);
begin
SignalConnection.Connect;
QAffaire.Open;
QDevis.Open;
Qproduction.Open;
end;
 
procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
SignalConnection.Disconnect;
end;
 
end.

La méthode connect a été ajoutée pa précaution car en fait les open déclenchent le Connect (idem pour le disconnect..)
et sur le beforeConnect je passe mes codes d'accès..

Je viens de m'apercevoir que j'aurais peut-être du mettre une gestion de traitement d'erreurs, car l'apparition du message "terminé" se produira aussi en cas d'erreur mais à priori la boucle se fait totalement vu les n°s affaire renvoyées.(j'ai un order by sur codedevis sur le query de devis)

et aussi faire un test avec AutoCommit à true (car le false indique le mode transactionnel) mais encore une fois je n'écris rien..


voilà j'en suis là pour l'instant...

[makowski]

Pfou ....

Tout est transaction !

un select se fait dans le contexte d'une transaction !

va lire ça :http://firebird-fr.eu.org/doku.php?i...s:transactions

et revois complètement la gestion des transactions dans tes programmes et arrète avec les commit retain

[cantador]

Bonsoir makowski,

ok tout est donc transaction :

"Dans Firebird “tout est transaction”, il n’est pas possible d’exécuter une requête hors du contexte d’une transaction. Vous ne le savez probablement pas si vous utilisez des suites de composants d’accès à Firebird comme le BDE et les objets TTable qui se chargent pour vous de gérer les transactions nécessaires à l’exécution des requêtes sous-jacentes au fonctionnement d’une TTable. Les autres, ceux qui utilisent des composants spécifiques à Firebird (et Interbase) comme UIB, IBX, FIB ou IBO savent qu’ils doivent systématiquement utiliser une transaction pour toute requête qu’ils font exécuter par leur SGBD préféré sous peine de voir les performances se dégrader considérablement. "

La propriété Autocommit (TIB_transaction)de l'outil externe est à false ce qui indique le mode transactionnel et c'est bien dans ce contexte qu'il est lancé. (Isolation :tiCommited)

Mais évidemment, ce n'est pas pour autant que je lance une transaction..
Autrement dit, si je traduis la doc, cela veut dire que je dois en lancer une
donc StartTransaction, mais comme je n'écris rien je n'ai pas à faire de commit..Comment fermer alors la transaction ? (le rollback étant déconseillé)

un peu plus loin on nous précise de travailler dans ce cas en mode lecture seule : isc_tpb_read.

"Mode d’accès en lecture seule qui n’autorise une transaction qu’à faire des opérations de type SELECT."

ok, mais alors dans ce cas comment écrire cette transaction ?

Voilà pour le premier point et pour le second :

J'avais testé les Commit et Rollback (dans le programme principal) et ensuite les CommitRetain et RollbackRetain.

Mais comme ces derniers sont beaucoup plus rapides à l'exécution que les premiers et ne déclenchent aucune erreur dans les données, je les ai adoptés...

Dans l'attente de ta réponse

A bientôt et merci

cantador

[makowski]

Mais évidemment, ce n'est pas pour autant que je lance une transaction..

si
RIEN NE SE FAIT HORS D'UNE TRANSACTION

les composants les démarre souvent implicitement, mais encore une fois
RIEN NE SE FAIT HORS D'UNE TRANSACTION

quand au commitretain, c'est un "faux" commit, un commit qui garde le contexte de la transaction et donc bloque l'évolution normale des transactions dans le moteur et finit par créer un immense historique des données et amène tot ou tard des pertes de performances.
cette notion a été inventé pour singer le comportement de Paradox avec les serveur SQL, en bref, une hérésie

donc StartTransaction, mais comme je n'écris rien je n'ai pas à faire de commit

FAUX
un commit ferme la transaction, même un select se commit

[cantador]

makowski,

Nous ne nous sommes pas compris..
Je voulais justement dire que le mode transactionnel(dans TIBO) n'impliquait pas le démarrage d'une transaction..
et compte tenu de tes infos que je devais en lancer une systématiquement.

Je vais tester tout çà et je te tiens informé des résultats.


@+

[cantador]

Ah si ya un truc quand même qui me taraude..

Pour les ouvertures de table, je n'utilise pas de TTable mais des TQuery.
Imagine un module avec 70 query à ouvrir d'entrée au démarrage du programme.
Comme chaque Query a son Select qlqchose..
tu ouvres une seule et unique transaction pour ouvrir les 70 dans une boucle ou tu encapsules chaque Query dans par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
 
try
    if not SignalConnection.DefaultTransaction.InTransaction then
      SignalConnection.DefaultTransaction.StartTransaction;
Query1.Close;
Query.Open;
  finally
    if SignalConnection.DefaultTransaction.InTransaction then
      SignalConnection.DefaultTransaction.Commit;

?

[makowski]

70 query à ouvrir d'entrée ????

Il faut penser en mode déconnecté, on ouvre une transaction (ou le composant le fait pour nous automatiquement) et on ferme la transaction dès que l'on n'a plus besoin de celle ci

si on veut afficher des grilles de lecture qui restent ouvertes longtemps, on utilise une transaction si possible readonly readcommited

sinon pour afficher des données "permanentes" le couple query - dataset en mémoire est très bien

[cantador]

"sinon pour afficher des données "permanentes" le couple query - dataset en mémoire est très bien"

C'est le choix que j'ai pris,mais cela ne me dit pas si je dois ouvrir
une transaction ou 70 ?

rien que pour l'ouverture bien entendu..

[cantador]

En clair, je souhaiterai pouvoir faire une seule transaction :

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
 
try
    if not TIB_Connection1.DefaultTransaction.InTransaction then
      TIB_Connection1.DefaultTransaction.StartTransaction;
 
        with DataModule do
          for i := 0 to ComponentCount - 1 do
            if Components[i] is TIBOQuery then
              if TIBOQuery(Components[I]).SQL.Count <> 0 then
              begin
                  TIBOQuery(Components[I]).Close;
                  TIBOQuery(Components[I]).Open;
              end;
  finally
    if TIB_Connection1.DefaultTransaction.InTransaction then
      TIB_Connection1.DefaultTransaction.Commit;
end;

qu'en penses-tu ?

cantador

[makowski]

qu'en penses-tu ?

j'en sais rien, je ne connais pas les propriétés par défaut de tes composants, ou si tu as changé leurs propriétés, mais il me semble que IBO a une doc assez complète non ? :
http://www.ibobjects.com/TechInfo.html

[cantador]

ok, je verrais ce point particulier..
je vais avoir les résultats du test sur l'outil externe incessamment..

En attendant, j'ai fait quelques tests sur l'appli principale avec "commit" et "CommitRetaining" :

Il doit y avoir un truc car j'ai au moins un facteur 10 en temps d'éxécution sur une simple validation.

Autrement dit, pour l'instant le "CommitRetaining" l'emporte haut la main.

@+

[cantador]

J'ai donc repris le code l'outil externe et j'ai introduit une transaction que j'ai clos par un commit dans le finally.(donc sûr qu'il y passe)
et le soft ne plante pas..

Résultats : le service FireBird s'est replanté en fin de programme et j'ai donc été obligé de le relancer.

Donc, pour l'instant rien de changé..

Mais c'est vrai que nous sommes dans un cas particulier puisque je lance un autre exécutable avec une autre connexion (avec le même alia bien entendu)
mais sur un poste installé en Client/serveur.
il faut aussi prendre en compte peut-être que je lance (j'ai fait le calcul) :
6000 requêtes SQL dans la boucle.

Peut-être y a t-il un paramétrage spécial du serveur ou un paramétrage particulier dans firebird.conf ?

Bref, pour l'instant, je n'ai pas d'explications et donc j'attends tes conseils avisés en ce domaine.

nb: pour les transactions, je n'ai rien trouvé dans la doc mis à part quelques grands principes généraux..

@bientôt

[cantador]

J'ai une info intéressante pour l'outil externe :

J'ai mis un point d'arrêt juste sur le test "InTransaction" du Finally :

Code :

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

1
2
3
4
5
6
7
  finally
    if SignalConnection.DefaultTransaction.InTransaction then
      SignalConnection.DefaultTransaction.Commit;
    Screen.Cursor := CrDefault;
    ShowMessage('terminé');
  end;

et j'ai constaté que déjà à ce stade le service est planté, c'est-à-dire donc juste avant le commit et avant le disconnect sur le close.

et le programme passe bien ensuite sur le commit..


??????????

@+

[makowski]

6000 requete dans une seule transaction ?
en firebird 1.5 ?
c'est ça ?
avec en plus d'autres transactions et connexions par ailleurs ?

sur quel serveur ? (memoire,proc, superserveur ou classic)

[cantador]

Oui, c'est bien le contexte makowski et pour répondre sur le serveur :
la machine principale : un bon serveur (je n'ai pas le type en tête) 1 giga de ram..) j'ai 12 gigas de disponible sur un disque de 160 gigas.
service firebird : Firebird-1.5.4.4910-0-Win32.exe (superserver)
Sql dialect:SQL3 CharSet :ISO8859_1

Mais le + inquiétant est que j'ai le même phénomène sans lancer la boucle en faisant un simple connect en utilisant l'assistant de connexion du TIB_connection et ensuite un disconnect !

Je vais changer tous les composants de l'outil et refaire un test car là franchement cà devient fort de café..

@bientôt

[cantador]

ah zut j'ai oublié la machine principale tourne sous NT4..
@+