TurboMagic 92 Posted January 1 This is a problem already discussed in German DP: https://www.delphipraxis.net/214354-backup-problem-nach-umstellung-auf-v3-0-embedded.html but the hints I got from there weren't working yet or not exactly how I wanted things to work. I've got an application developed in Delphi 11.3 which used a Firebird V2.5 embedded database. Now I wanted to migrate it to a newer version (currently 3.0, but at the end 4.x is planned). The migration worked for the main part of the application, but it fails for the backup/restore menus in the application. The failure shown is: [FireDAC][Phys][FB]Unable to complete network request to host "xnet://Global\FIREBIRD". [FireDAC][Phys][FB]invalid service handle [FireDAC][Phys][FB]invalid service handle This is strange, because the same method for performing a restore is used in this application at startup when a database backup file is found which stems from an update of the application. That's needed to be able to move to a newer database file format verion (ODS in Firebird terms). In that scenario the restore is run before there was an open TFDConnection. The failure case happens when I invoke the restore menu in the application. But that one closes the connection first and after some modification even frees the connection and the DriverLink objects. I also created a separate small test application which just implements the restore using the unints from the main application. When I set a breakpoing in the main application on the close call of the DB connection, let that one get carried out and then halt the main application in the debugger the test application will present a different error thant the one described above. I modified the main application then to just close the connection in the restore menu and then do nothing more. Then I can run my separate test application and perform the restore. I also checked FDManager.ConnectionCount when I close that connection. Before it is 1 and after close it is 0, so there's no connection pooling used in that application. => what else can this be and why does it work, when running the restore before having opened any db connection? Share this post Link to post
TurboMagic 92 Posted January 1 Here's the code used to initialize the restore component: FFBDriverLink := TFDPhysFBDriverLink.Create(nil); FFBDriverLink.VendorLib := 'D:\Projects\MyApp\Win32\Debug\Database\fbclient.dll'; FFBDriverLink.Embedded := true; FFBRestore := TFDIBRestore.Create(nil); FFBRestore.ConnectTimeout := 0; FFBRestore.Database := DatabaseFileName; FFBRestore.DriverLink := FFBDriverLink; FFBRestore.Password := c_DBPassword; FFBRestore.QueryTimeout := 2; FFBRestore.UserName := c_DBUserName; FFBRestore.Options := [roReplace]; FFBRestore.Protocol := TIBProtocol.ipLocal; FFBRestore.Verbose := true; FFBRestore.AfterExecute := OnRestoreFinishedInternal; FFBRestore.OnProgress := OnRestoreProgressInternal; FFBRestore.OnError := OnRestoreErrorInternal; Share this post Link to post
Vandrovnik 211 Posted January 1 I had similar problem with Firebird 3 using IBX components. Solved by using Firebird 4 🙂 Share this post Link to post
TurboMagic 92 Posted January 1 Oh, really? Then I should directly try to migrate to FB 4 embedded. I guess you used embedded? As I guess I wouldn't have the issues using the server variant... Share this post Link to post
gkobler 38 Posted January 1 Shouldn't the client library be called embeded.dll instead of fbclient.dll? And as far as I know, the Firebird installation must be in the Project.exe directory. But I could be wrong. Share this post Link to post
TurboMagic 92 Posted January 1 Starting with FB 3.0 you are wrong. The client library is named like the client/server one now, as they try to unify things. 1 Share this post Link to post
gkobler 38 Posted January 1 OK, there are some infos about embedded from Helen and Vlad read the PDF https://www.firebirdsql.org/en/news/embedded-server-in-firebird-3/ May that have some infos for you. Share this post Link to post
gkobler 38 Posted January 1 (edited) find some other links in the google firebird-support group See the Firebird 3 release notes. Connection strings that are only a file path will now use embedded. See https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rlsnotes30.html#rnfb30-engine-modes-protocols and https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rlsnotes30.html#rnfb30-compat-winlocal Also read https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rlsnotes30.html#rnfb30-engine Edited January 1 by gkobler Share this post Link to post
TurboMagic 92 Posted January 1 Ok, I did the Firebird 4.0 Migration now and Backup/Restore basically work again. I've got something else in im application now when restoring, but that's something on my side. Share this post Link to post
TurboMagic 92 Posted January 2 (edited) Ok, I'm pleased too early: when trying to perform a backup with FB 4.0 while the DB Connection is open, it fails with an I/O error because the DB file is already open. 😞 And I also found out now that the cases where it worked were because of having installed and 4.0 FB server on the same VM for using a DB tool and having forgotten to turn off the service 😞 With 2.5 embedded this wasn't a problem as far as I can remember. That would mean now, that I have to close the DB connection and close the DriverLink, then I can perform the backup and then I need to reopen the DB connection and what's more: all datasets I have, which pointed on this DB connection and which might be open at this point in time become invalid. I would have to recreate them all. Correct? Or is there a way I can perform a backup while still having an open DB connection using the embedded version of Firebird? I could understand for the Restore, but not for the Backup... And yes, the other option would be to not use Embedded but the regular client/server variant. Edited January 2 by TurboMagic Share this post Link to post
Uwe Raabe 2055 Posted January 2 You can try to set the connection offline during the backup. For more information see Offlining Connection (FireDAC) Share this post Link to post
TurboMagic 92 Posted January 2 Thanks for the offline/online hint! I'll look at this later! Share this post Link to post
TurboMagic 92 Posted January 2 Strange. When I call offline on the DB connection and then run the backup from the same application I get this xnet error. But when I call offline on the DB connection followed by exit as next statement and place a breakpoint on that, I can run that application so it stops on the exit statement and then perform a backup from a separate test application which uses the same code to perform the backup and the backup works. Why doesn't it work when I call that from the same application? Share this post Link to post
Uwe Raabe 2055 Posted January 2 Maybe this is the time to prepare a minimal test case so that we can reproduce. Share this post Link to post
TurboMagic 92 Posted January 2 Sigh! That was the idea of my own small backup/restore test app I developed using code from the main app. But when using that it always works 😞 Ok, one thing is left to check: these auto reconnect options of the DB connection. But I doubt that's the issue, but need to check. Share this post Link to post
Davide Angeli 44 Posted January 3 I don't know if this can help and perhaps you have already done this, but according to FB4 documentation, to use embedded version to connect to one database from several applications, you need to set the parameter "ServerMode" as "Classic" in firebird.conf (this was the default behaviour of FB2.5 embedded now changed in FB4 in "Super"). https://ib-aid.com/download/docs/fb4migrationguide.html (read section "1.5 Installing Embedded") firebird.conf comments: # ============================ # Settings for Architecture Configuration # ============================ # # Controls the method Firebird engine uses to work with databases and # related Firebird server startup parameters. # # The values are: # Super / ThreadedDedicated - databases are opened exclusive by single server process, # attachments share single DB pages cache inside process # SuperClassic / ThreadedShared - databases are opened by single server process, # but it does not prevent opening them in other processes (embedded access), # each attachment has its own DB pages cache # Classic / MultiProcess - for each attachment to server a separate process is started, # each database may be opened by multiple processes (including local ones for # embedded access), each attachment (process) has its own DB pages cache # # Type: string # #ServerMode = Super 1 Share this post Link to post
TurboMagic 92 Posted January 21 I still have my backup problem. Back then I started to implement a small test application. Today I added database opening, closing and reading out of some data capabilities for further testing/investigation. That test works as follows and doesn't show the error: 1. Open database 2. Read out some data 3. Perform a backup If I do similar things it failed with that XNET error. During implementing the test program I found out that this: FDriverLink.DriverID := 'FB'; was in the code instead of this: FDriverLink.DriverID := 'IB'; I changed my real application now and guess what? It works! 😉 Must have been a leftover from the times where dbExpress had been used and no FB driver existed yet. Share this post Link to post
Tommi Prami 130 Posted January 22 On 1/1/2024 at 4:10 PM, TurboMagic said: Now I wanted to migrate it to a newer version (currently 3.0, but at the end 4.x is planned). Skip 4.x, and go directly to the FB5. From point of your app, FB4.x and FB5 are more than less the same, only minor ODS version change, form 13.0 to 13.1, so no new data types etc. If scared of new release, wait for couple of weeks/months to see is there something needed to fix (that you care about). If there is valid reason not to go to the FB5, I would for sure to skip FB3 at least, would jump directly to the FB 4.0.4.. Also I would try to avoid setting data type compatibility mode to some to the old version, I would just fix DB and code, should not take too long. On 1/1/2024 at 4:10 PM, TurboMagic said: This is a problem already discussed in German DP: https://www.delphipraxis.net/214354-backup-problem-nach-umstellung-auf-v3-0-embedded.html but the hints I got from there weren't working yet or not exactly how I wanted things to work. Embedded needs exclusive access to the DB, so you need to close all connections to the DB, at the App and external Db tools etc. Not sure that is this the problem tough, because I saw no error message, and did not go through the german forum thoroughly. -Tee- Share this post Link to post
TurboMagic 92 Posted January 22 I'm on 4.0.x now and will look at the change log document for V5.0 soon. 1 Share this post Link to post