Perte de données firebird zeos delphi7

**mina24** · 06/10/2016, 16h53

Bonjour,
J'ai un sérieux problème avec mon application (delphi7, composant zeoslib, firebird 2.5) . Il m'arrive (2 fois)de perdre quelques enregistrements dans plusieurs tables (un travail d'une journée ou plus).
je m'explique , la propriété autocommit de Zconnection est à true .Lorsque je ferme mon application j'ai programmé une sauvegarde automatique(gbak).
Le lendemain je ne trouve pas ce que j'ai fais la veille mais quand je fais un restaure de ma base je retrouve tous mes enregistrements

.
Quelle est la cause de perte de données dans firebird? .

En suivant mon source j'ai constaté qu'à la fermeture de mon programme je n'ai pas mis zconnection.connected à false

es ça qui peut être la cause de mes soucis?, comme ce n'est pas tout les jours que je perd des données je ne peut pas être sûr de cela

.
Merci.

**SergioMaster** · 07/10/2016, 08h40

Bonjour,

Envoyé par mina24

Le lendemain je ne trouve pas ce que j'ai fais la veille mais quand je fais un restaure de ma base je retrouve tous mes enregistrements

.
...
En suivant mon source j'ai constaté qu'à la fermeture de mon programme je n'ai pas mis zconnection.connected à false

es ça qui peut être la cause de mes soucis?
Quelle est la cause de perte de données dans firebird? .

A mon avis il y a quand même une transaction mal fermée (ce n'est pas parce que AutoCommit est à true que cela ne peut pas arriver). Ce qui me fait dire cela c'est que la transaction semble être récupérée par la restauration.
Donc oui, peut être que fermer la connexion va clore cette transaction mais je pense que ce n'est pas la seule piste à explorer car, d'après ce que j'ai compris cela n'arrive pas toujours ?
Première chose à faire, après clôture du programme[Edit] Mais avant de faire le GBAK[/Edit], vérifier s'il y a encore des transactions

Code SQL :

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

SELECT * FROM RDB$TRANSACTION

https://ib-aid.com/download/docs/fir...-transacs.html

Ensuite vérifier qu'il n'y a pas des tables (donc en UPDATE) non fermées dans le programme (toujours préférer un ZReadOnlyQuery pour les affichages dans des grilles) si c'est le cas toujours fermer ces tables avant la clôture de la base.

un exemple de ce qui peut arriver avec un Table ouverte et une requête d'insertion sur cette même table :
La Table est ouverte sur le DBGrid, pour une raison x elle est en mode Edit. J'exécute une requête INSERT dans la table puis je ferme le programme, la modification sur la table non validée . Il faudrait faire des essais mais AMHA il y a de fortes chances que la transaction sur la table soit en Limbo et il n'est pas sûr que l'INSERT soit pris en compte.

Reste enfin la piste de la mémoire cache (j'y crois pas trop)

**aimer_Delphi** · 07/10/2016, 11h11

pour ma part je manipule mes transactions manuellement, après chaque insert ou update...

Code :

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

1
2
3
4
try
  matansaction.commit
except 
 matransaction.rollback;

cordialement.

**mina24** · 09/10/2016, 10h12

@SergioMaster Merci pour toute ces explications je vais explorer toute ces pistes.

**mina24** · 11/10/2016, 10h52

Bonjour

Envoyé par SergioMaster

Première chose à faire, après clôture du programme vérifier s'il y a encore des transactions

Ensuite vérifier qu'il n'y a pas des tables (donc en UPDATE) non fermées dans le programme si c'est le cas toujours fermer ces tables avant la clôture de la base.

Es que ce bout de programme convient il dans before diconnect de la base de donné ?

Code :

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

1
2
3
if base.InTransaction then
          base.Commit;
          FermerTables;

avec la procédure FermerTables comme suit:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 procedure TDataM.FermerTables;
var CompteurTable : integer;
begin
  for CompteurTable := ComponentCount -1 downto 0 do
    if (Components[CompteurTable] is TZQuery) then
        begin
        if TZQuery(Self.Components[CompteurTable]).Active then
         begin
            TZQuery(Self.Components[CompteurTable]).Close;
           //showmessage(TZQuery(Self.Components[CompteurTable]).Name); c'était pour afficher les ZQuery non fermées
           end;
         end;
end;

**SergioMaster** · 12/10/2016, 08h27

Bonjour,

AMHA le test en ligne 7 n'est pas utile (sauf bien sûr pour avoir l'affichage)

Code :

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

1
2
3
4
5
6
        if TZQuery(Self.Components[CompteurTable]).Active then
         begin
            TZQuery(Self.Components[CompteurTable]).Close;
           //showmessage(TZQuery(Self.Components[CompteurTable]).Name); c'était pour afficher les ZQuery non fermées
           end;
         end;

remplacable par
TZQuery(Self.Components[CompteurTable]).Active :=False;il n'y a pas de TZTable ? << c'était surtout sur celles-ci que je posais des doutes
et pas de TZReadOnlyQuery << bien mieux quand l'ensemble ne sera qu'en lecture seule

pour le BeforeDisconnect Base.Commit c'est bien mais s'il y a une erreur un

Code :

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

Try Base.Commit Except Base.Rollback end;

d'autre part, s'il y a bien un endroit où tester (et donc mettre un message pour déboguer) c'est bien à cet endroit !
mais je pense qu'il faut que les Ensemble de données soient fermés avant !

Code :

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

1
2
3
4
5
6
7
8
FermerTables;
if base.InTransaction then
     try
        //  showmessage('il y avait des transactions en cours !'); 
          base.Commit;
     except
          base.rollback;
    end;

mais quelles seraient les implications sur le programme s'il y avait un rollback ? (ça ne devrait pas arriver sauf cas de perte de connexion au réseau peut être)