Backup Problem nach Umstellung auf V3.0 embedded

[TurboMagic]

Hallo,

ich stelle in einer 11.3 Anwendung gerade von der bisher genutzten Firebird 2.5 Embedded
auf die 3.0 Embedded um und stelle nun fest, dass das Backup im Programm immer fehlschlägt,
weil noch jemand anderes die DB Datei auf hat.

Mir ist auch klar, wer der andere ist: die normale DB Connection des selben Programs.
Nur: in V2.5 ging das problemfrei parallel...
Ist das in 3.0 (embedded) anders? Weiß das jemand?

Ja, der Lösungsansatz muss jetzt wohl sein, dass das Programm so umgebaut wird, dass es
zuerst die DB Verbindung schließt, bevor es ein Backup oder Restore fahren will...
...wäre mir aber natürlich lieber wenn's auch nanders ginge...

Grüße
TurboMagic

[TurboMagic]

Hm, eine weitere Recherche ergab, dass nach Umstellung auf 3.0
das Backup wohl nur funktioniert hatte, weil ich in der Entwicklungs VM
auch einen 3.0 Server installiert habe, da ein anderes Tool mit der
Embedded Variante nicht klar kam.

Jetzt versuche ich das Backup Erstellen zu reparieren, scheitere aber
am Protocol. Wenn ich TFDIBBackup.Protocol nichts zuweise, bekomme ich
eine Fehlermeldung, die darauf hinweißt, dass XNET benutzt werden soll,
was m.W. unter 3.0 aber nicht mehr geht. Ich habe mal versucht .Protocol
auf ipLocal oder ipTCPIP zu setzen, damit gibt's dann aber eine Fehlermelung

Code:

Cannot attach to services manager
service :service_mgr is not defined
[FireDAC][Phys][FB]invalid service handle

Hier mein Code zum erzeugen der Backup Instanz:

Delphi-Quellcode:

constructor TDBBackup.Create(const DatabaseFileName : string;
                             const VendorLib        : string);
begin
  FFBDriverLink             := TFDPhysFBDriverLink.Create(nil);
  FFBDriverLink.VendorLib   := VendorLib;
  FFBDriverLink.Embedded    := true;

  FFBBackup                 := TFDIBBackup.Create(nil);
  FFBBackup.ConnectTimeout  := c_DBBackupConnectTimeout;
  FFBBackup.Database        := DatabaseFileName;
  FFBBackup.DriverLink      := FFBDriverLink;
  FFBBackup.Password        := c_DBPassword;
  FFBBackup.QueryTimeout    := c_DBBackupServiceTimeout;
  FFBBackup.UserName        := c_DBUserName;
  FFBBackup.Verbose         := true;

  FFBBackup.Protocol        := TIBProtocol.ipTCPIP;

  FFBBackup.AfterExecute    := OnBackupFinishedInternal;
  FFBBackup.OnProgress      := OnBackupProgressInternal;
  FFBBackup.OnError         := OnBackupErrorInternal;
end;

[..] // später Erstellen des Backups:

procedure TDBBackup.CreateBackup(const FileName: string);
begin
  FFBBackup.BackupFiles.Clear;
  FFBBackup.BackupFiles.Add(FileName);
  FFBBackup.Backup;
end;

Gibt es ein generelles Kompatibilitätsproblem mit FireDAC's
TFDIBBackup mit Firebird Embedded >= 3.0?

Grüße
TurboMagic

[IBExpert]

in fb3 embedded ist per default der superservermodus aktiv, oder mit anderen worten
eine connection braucht exklusiven lock auf die datenbank datei.

netterweise kann man aber auch beim embedded in fb3 per conf auf classic umstellen
https://www.ibphoenix.com/files/Embedded_fb3.pdf

"#ServerMode = Super
As such, it needs to acquire an exclusive lock on the database file to connect and, while
connected, it prevents shared connections from other engine instances. With this
configuration, it is not possible, for example, to have client/server clients connected
simultaneously with browser clients attached to the same database through an intranet
application that uses an embedded engine.
The solution is to run your embedded engine as a [Super]Classic process in concert with
your Superclassic or Classic server. Uncomment the ServerMode parameter in the
firebird.conf of your embedded structure and set it to Classic or Superclassic:
ServerMode = Classic
Note, for the embedded engine, Classic and Superclassic are equivalent."


Sind aber auch noch andere ganz gute hinweise in der datei da.

Ob da firedac selber dafür geeignet ist, weiss ich aber nicht, weil wenn die da vielelicht intern
wieder irgendwelche tricksereien nutzen, kann es sein, das da die ursache für dein Problem ist
Es hindert dich niemand daran, auch mit dem embedded die passende gbak.exe (in der passenden
32 oder 64 bit version wie die fbclient.dll) auszuliefern und mit der dann ein kommadozeilen
backup zu machen aus deinem programm.

[TurboMagic]

Danke für die Tipps.

1. Eigentlich möchte ich bald auf FB4 gehen
2. Exklusiver Zugriff sollte machbar sein, aber wenn ich
Verbindungsprobleme wie derzeit hab, ist es fruchtlos
3. GBak aufrufen ist prinzipiell möglich, nur nicht ganz
was ich will. Bisher in 2.5 hat es ja auch so
funktioniert. Ich Frage mich halt warum das Verbindungs-
problem existiert.
4. Ich werde das mal versuchen in einem separaten kleinen
Programm zu testen...

Grüße und guten Rutsch

TurboMagic

[IBExpert]

ist bei fb4 identisch, gäbe auch aktuell eigentlich keine grund mehr, mehr fb3 zu bleiben aus meiner sicht

[TurboMagic]

Da hast du sicher recht. Ich wollte halt nicht gleich den großen Sprung machen,
falls doch noch was ist.

[TurboMagic]

Komische neue Erkenntnis:
gibt es beim Start des Proghramms eine Backup Datei mit einem bestimmten Namen,
so wird diese erfolgreich wiederhergestellt, weil das dann vom Programm Update stammt.

Nur benutze ich die selbe Restore Routine später vom Programm GUI aus, schlägt das
mit dem XNET Fehler oben fehl. Inzwischen hab' ich auch extra die normale DB-Verbindung
komplett geschlossen und das Protocol der TFDIBRestore Komponente auf ipLocal gesetzt.
Verhalten bleibt aber gleich... :-(

[TurboMagic]

Nächste Tests:

1. Ich habe ein kleines separates Restore VCL Programm geschrieben,
dass dafür genau die selben Dateien benutzt wie das richtige Programm.
Nur den Pfad zur Backup Datei hart codiert. Ausgabepfad für .exe und
dcus ist derselbe, den auch das richtige Programm benutzt, da die FB
DLLs dort in einem Unterordner drin liegen.

2. Dieses Programm kann ich problemlos ausführen und der Restore erfolgt
fehlerfrei.

3. Rufe ich es auf, während die andere Anwendung die DB offen hat kommt
eine Fehlermeldung, dass die DB-Datei nicht beschrieben werden kann.
War zu erwarten.

4. Ändere ich das Restore im richtigen Program so ab, dass es nach dem
Schließen der DB-Verbindung (d.h. noch vor dem Restore aufruf) im
Debugger anhält kann ich parallel mit dem externen Programm problemlos
ein Restore machen.
=> mein eigentliches Programm blockiert das dann nicht mehr, d.h. die
DB-Verbindung ist dann wirklich zu.

5. ProcessMonitor zeigt auch nur Zugriffe auf die richtige fbclient.dll.

=> irgendwas im richtigen Programm muss noch falsch sein, nur was?

[Uwe Raabe]

Wenn du mit pooled Connections arbeitest, deine FireDAC Connections also mittels ConnectionDefName zugewiesen hast, könntest du mal ein

Delphi-Quellcode:

FDManager.CloseConnectionDef(<name>)

versuchen.

[TurboMagic]

Hallo,

danke für den Hinweis, den ich im neuen Jahr mal untersuche, auch wenn ich nicht glaube das mich das weit bringt.
Weil ich nicht glaube etwas mit pooled connections angestellt zu haben. Ich denke, bei mir läuft alles über eine
Connection.

Aber zu untersuchen ist es. Auch hatte ich inzwischen die Idee mich mal in die Events vom FBDriverLink zu hängen
um zu sehen wo der wirklich geladen und entladen wird.

Grüße

TurboMagic