Firebird 3.0 problem

[TurboMagic 91]

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?

[TurboMagic 91]

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;

 

[Vandrovnik 202]

I had similar problem with Firebird 3 using IBX components. Solved by using Firebird 4 🙂

[TurboMagic 91]

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...

[gkobler 31]

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.

[TurboMagic 91]

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.

[gkobler 31]

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.

[gkobler 31]

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

[TurboMagic 91]

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.

[TurboMagic 91]

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

[Uwe Raabe 1888]

You can try to set the connection offline during the backup. For more information see Offlining Connection (FireDAC)

[TurboMagic 91]

Thanks for the offline/online hint! I'll look at this later!

[TurboMagic 91]

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?

[Uwe Raabe 1888]

Maybe this is the time to prepare a minimal test case so that we can reproduce.

[TurboMagic 91]

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.

[Davide Angeli 41]

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

 

 

 

[TurboMagic 91]

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.

[Tommi Prami 123]

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-

[TurboMagic 91]

I'm on 4.0.x now and will look at the change log document for V5.0 soon.