Soucis avec une restauration de base

**JCD59** · 23/07/2018, 16h12

Bonjour,
J'ai fait un petit programme qui gère plusieurs tables avec une base Firebird

J'y ai introduit une partie sauvegarde/restauration de cette base.

La sauvegarde s'effectue sans soucis.

La restauration ne s'effectue pas, j'ai toujours un message que le fichier est occupé par un autre processus, pourtant je déconnecte bien la base avant de faire l'opération. Voici une partie du code

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
procedure Tfich_sauv_rest_base.btactionsauv_restClick(Sender: TObject);
 
begin
        if messagedlg('CONFIRMEZ-VOUS CETTE OPERATION ?      SOURCE '+LabeledEdit_chemin_base_source.Text +' VERS DESTINATION  ' + edit2.Text,mtconfirmation,[mbyes,mbcancel],0)<>mryes
then
begin
Sysutils.Abort;
end
else
  module_bases.ZConnection1.Connected:=false;
  if CopyFile(PChar(scrfilename),PChar(destfilename),false) then showmessage ('OPERATION REUSSIE !') else showmessage (SysErrorMessage(GetLastOSError));
end;

Je me demande cela ne pourrait pas provenir d'un TFilenameedit placé en amont avec un filtre sur ma base, activé en même temps que la form.

J'ai vérifié, la copie (via Windows) fonctionne bien, quand mon petit programme est fermé, c'est donc bien une erreur chez moi.

**JCD59** · 23/07/2018, 16h52

Envoyé par JCD59

Bonjour,
J'ai fait un petit programme qui gère plusieurs tables avec une base Firebird

J'y ai introduit une partie sauvegarde/restauration de cette base.

La sauvegarde s'effectue sans soucis.

La restauration ne s'effectue pas, j'ai toujours un message que le fichier est occupé par un autre processus, pourtant je déconnecte bien la base avant de faire l'opération. Voici une partie du code

Je me demande cela ne pourrais pas provenir d'un TFilenameedit placé en amont avec un filtre sur ma base, activé en même temps que la form.

J'ai vérifié, la copie (via Windows) fonctionne bien, quand mon petit programme est fermé, c'est donc bien une erreur chez moi.

Je confirme que cela doit bien être mon Tfilenameedit qui doit doit générer cette erreur, car j'ai saisi à un autre endroit sans cet élément le même code avec les noms de fichiers en 'dur" et là cela fonctionne......

J'avais initialement Filelistbox, mais je souhaité avoir la date des fichier ce que me donne Tfilenameedit.

**BeanzMaster** · 24/07/2018, 01h03

Bonsoir

Pour ajouter une colonne "date" à un TShellListView (Ton FileListBox je suppose)

voici comment procéder

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
Procedure TMainForm.FormCreate(Sender: TObject);
Var
  aCol : TListColumn;
Begin
  aCol := ShellListView.Columns.Add;
  aCol.Caption := 'Date';
  aCol.AutoSize := true;
end;
 
// Évènement FileAdded
Procedure TMainForm.ShellListViewFileAdded(Sender: TObject; Item: TListItem);
Var
  dt: TDateTime;
Begin
  FileAge(ShellListView.Root+Item.Caption, dt);
  Item.SubItems.Add(FormatDateTime('DD/MM/YYYY  hh:mm',Dt));
end;

Le TFilenameedit doit avoir un bug, car ce n'est pas normal qu'il te "lock" le fichier sélectionné

Il semble que function TFileNameEdit.CreateDialog(AKind: TDialogKind): TCommonDialog; de l'unité "lcl\EditBtn.pas" la boite de dialogue créée avec cette fonction n'est pas libérée, correctement. Ce qui pourrais donc provoquer cette erreur. Je testerai plus tard et enverrai une note dans le "BugTracker" au besoin.

Bonne fin de soirée

**BeanzMaster** · 24/07/2018, 01h32

Question bête, mais quand tu utilises ton TFileNameEdit, tu ouvres donc ta base si je comprend bien et tu déconnecte bien ta base avec module_bases.ZConnection1.Connected:=false; si ça se trouve c'est ZEOS qui ferme mal la connection et non ton filenameedit. En regardant le code de celui-ci je ne comprend pas en quoi et ou le fichier sélectionné peut-être "locker". Mise à part cette histoire de destruction mais je ne pense pas car je viens de faire un test simple

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
Unit Unit1;
 
{$mode objfpc}{$H+}
 
Interface
 
Uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, EditBtn, StdCtrls;
 
Type
 
  { TForm1 }
 
  TForm1 = Class(TForm)
    btnCopy: TButton;
    edtDir: TDirectoryEdit;
    edtFile: TFileNameEdit;
    Label1: TLabel;
    Procedure btnCopyClick(Sender: TObject);
    Procedure edtDirChange(Sender: TObject);
  private
 
  public
 
  End;
 
Var
  Form1: TForm1;
 
Implementation
 
{$R *.lfm}
 
{ TForm1 }
 
Procedure TForm1.btnCopyClick(Sender: TObject);
Var
  ScrFileName, DstFileName : String;
Begin
 ScrFileName := edtFile.FileName;
 DstFileName := edtDir.Directory + PathDelim + ExtractFileName(edtFile.Text);
 if messagedlg('CONFIRMEZ-VOUS CETTE OPERATION ?      SOURCE '+edtFile.Text +' VERS DESTINATION  ' + edtDir.Text,mtconfirmation,[mbyes,mbcancel],0)=mryes then
 begin
  if CopyFile(PChar(ScrFileName),PChar(DstFileName),false) then showmessage ('OPERATION REUSSIE !') else showmessage (SysErrorMessage(GetLastOSError));
 End;
end;
 
End.

Une fois compilé et lancé J'ai choisi comme fichier, l'exécutable de ce test. Et le fichier à été parfaitement copié.

Il me semble donc que le problème se trouve du coté de ZEOS et de la commande de déconnection module_bases.ZConnection1.Connected:=false; tu as peut-être besoin de détruire ton objet "module_bases" .La simple déconnexion ne semble pas suffire. Il existe peut-être une autre méthode ou fonction dans ZEOS. Mais je ne peux pas t'aider car je connais que très peu cette suite de composant.

**JCD59** · 24/07/2018, 10h56

Envoyé par BeanzMaster

Question bête, mais quand tu utilises ton TFileNameEdit, tu ouvres donc ta base si je comprend bien et tu déconnecte bien ta base avec module_bases.ZConnection1.Connected:=false; si ça se trouve c'est ZEOS qui ferme mal la connection et non ton filenameedit. En regardant le code de celui-ci je ne comprend pas en quoi et ou le fichier sélectionné peut-être "locker". Mise à part cette histoire de destruction mais je ne pense pas car je viens de faire un test simple

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
Unit Unit1;
 
{$mode objfpc}{$H+}
 
Interface
 
Uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, EditBtn, StdCtrls;
 
Type
 
  { TForm1 }
 
  TForm1 = Class(TForm)
    btnCopy: TButton;
    edtDir: TDirectoryEdit;
    edtFile: TFileNameEdit;
    Label1: TLabel;
    Procedure btnCopyClick(Sender: TObject);
    Procedure edtDirChange(Sender: TObject);
  private
 
  public
 
  End;
 
Var
  Form1: TForm1;
 
Implementation
 
{$R *.lfm}
 
{ TForm1 }
 
Procedure TForm1.btnCopyClick(Sender: TObject);
Var
  ScrFileName, DstFileName : String;
Begin
 ScrFileName := edtFile.FileName;
 DstFileName := edtDir.Directory + PathDelim + ExtractFileName(edtFile.Text);
 if messagedlg('CONFIRMEZ-VOUS CETTE OPERATION ?      SOURCE '+edtFile.Text +' VERS DESTINATION  ' + edtDir.Text,mtconfirmation,[mbyes,mbcancel],0)=mryes then
 begin
  if CopyFile(PChar(ScrFileName),PChar(DstFileName),false) then showmessage ('OPERATION REUSSIE !') else showmessage (SysErrorMessage(GetLastOSError));
 End;
end;
 
End.

Une fois compilé et lancé J'ai choisi comme fichier, l'exécutable de ce test. Et le fichier à été parfaitement copié.

Il me semble donc que le problème se trouve du coté de ZEOS et de la commande de déconnection module_bases.ZConnection1.Connected:=false; tu as peut-être besoin de détruire ton objet "module_bases" .La simple déconnexion ne semble pas suffire. Il existe peut-être une autre méthode ou fonction dans ZEOS. Mais je ne peux pas t'aider car je connais que très peu cette suite de composant.

Merci pour vos réponses

Tout d'abord mon test coté dans mon second message, est improductif. Certes je n'ai pas eu de retour d'erreur de windows, mais il me semble que le transfert ne s'effectue pas.

Ensuite, j'ai essayé de le faire par windows avec mon logiciel ouvert et c'est Firebird qui reste actif, donc la réflexion de BeanzMaster est dans le vrai, je vais donc creuser cette voie!

**JCD59** · 24/07/2018, 15h07

Je me suis hasardé à utiliser le composant TFBAdmin.

Pour une utilisation en local j'ai écris ce code

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
procedure Backup(Database, Backupfile: string);
var
  Admin: TFBAdmin;
begin
  Admin := TFBAdmin.Create(nil);
  try
    Admin.UseExceptions := True;
    Admin.User := 'SYSDBA';
    Admin.Password := '***'; // ( J'ai bien mon mot de passe de connexion)
    Admin.Port := 3050;
    admin.connect;
    Admin.OnOutput := @fich_sauv_rest_base.logadm;
    Admin.Backup(Database, Backupfile, [IBBkpVerbose]);
  finally
    Admin.Free; //disconnects automatically
  end;
end;

Je n'ai testé que que la backup pour l'instant et cela ne se passe pas bien

La backup se lance, mais à un stade se bloque. J'arrive à obtenir un message SQL Error connection Shutdown Error code -902 Can't format message 13:98

J'ai une trace du déroulé jusqu'à ce stade, elle est en document joint

Là je coince

Soucis avec une restauration de base

Lazarus Pascal

Vue hybride

Discussions similaires

Partager

Partager