Classic problem: "xnet://Global \Local\FIREBIRD"

[Stanislav Hruška]

Project JasotSVB.exe raised exception class EIBNativeException with message '[FireDAC][Phys][FB]Unable to complete network request to host "xnet://Global\FIREBIRD".'.

I'm already desperate. Thanks.

W10 64b, Delphi 11, FireDAC, application 32b. The internet didn't help me. FB ver 3.0.7.

The paths are right. I shut down the server for testing. My program settings:

  dtmdBasic.fdfbdrlnkFoc.VendorHome := '';

  dtmdBasic.fdfbdrlnkFoc.VendorLib := '';

  dtmdBasic.fdfbdrlnkFoc.VendorLib := VendorDir;               //  OK

  dtmdBasic.fdfbdrlnkFoc.Embedded := FCertificate.IsEmbedded;  //  True

  Connection := dtmdBasic.conFB;

  Connection.Connected := False;

  Connection.LoginPrompt := False;

  Connection.Params.Add('CharacterSet = csWin1250');

  Connection.Params.Database := FBasicDir.UserDataDir + FFileName;

  Connection.Params.DriverID := 'FB';

  Connection.Params.Database := 'Password = masterkey';

  Connection.Params.Add('Port = 3050');

  Connection.Params.Add('Protocol = ipLocal');

  Connection.Params.UserName := 'SYSDBA';

[Mark Rotteveel]

Does setting `dtmdBasic.fdfbdrlnkFoc.Embedded` to true control whether
you want to use Firebird Embedded? If so, why set that when you want to
connect to a Firebird server (judging by the rest of your config)? IIRC,
this error happens when you try to connect without host name (e.g. when
you'd use Firebird Embedded), but fbclient.dll cannot actually find the
Embedded database engine. It then tries to connect to the server using
XNET, but given the error you don't have a Firebird server running on
the local host (which seems to match with the fact you shut down
Firebird server).

Decide what you want to do:

- Connect to a server
- Connect to Firebird Embedded.

If you want to use Firebird Embedded from a 32-bit application, you must
have a 32-bit fbclient.dll, and a 32-bit plugins\engine12.dll (and other
supporting files) in the same location as the fbclient.dll you're using.

Mark

[Stefan Heymann]

There is a mismatch between xnet and "Protocol = ipLocal".

So if you want to use xnet you should't specifiy ipLocal (which is the IP protocol aka TCP/IP) as the protocol. And "Global\Firebird" is a relative path name, I would specify either an alias or a complete absolute path and filename to your database.

HTH


Regards

Stefan


----- Ursprüngliche Nachricht / Original Message -----
Von/From: Stanislav Hruška <sthru...@gmail.com>
Gesendet/Date: 30.11.2021 08:28
An/To: firebird-support <firebird...@googlegroups.com>
Betreff/Subject: [firebird-support] Classic problem: "xnet://Global \Local\FIREBIRD"

--
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/35f7438d-12e3-4a54-a93c-e9fa5c2ad70en%40googlegroups.com.

[Mark Rotteveel]

On 2021-11-30 10:47, Stefan Heymann wrote:
> There is a mismatch between xnet and "Protocol = ipLocal".
>
> So if you want to use xnet you should't specifiy ipLocal (which is the
> IP protocol aka TCP/IP) as the protocol. And "Global\Firebird" is a
> relative path name, I would specify either an alias or a complete
> absolute path and filename to your database.

XNET://Global\Firebird is an internal address used by Firebird. It is
not a database path specified by the user. This error occurs when you're
trying to connect to a database without specifying a hostname, and the
Firebird Embedded engine is not available, and Firebird server is not
running on localhost.

Mark

[Stanislav Hruška]

Thank you for your response.

I control the basic data. I have been looking for a solution on the Internet for a long time. So I know the reason.

I want to use Embedded. The first time I learn I must to use engine12.dll. I have FB 64b installed. Where should I get engine12.dll for 32b? Because of this, I do not intend to install FB 3.0.7 32b.

The fbclient.dll program finds it. And the right version.

Dátum: utorok 30. novembra 2021, čas: 10:52:58 UTC+1, odosielateľ: ma...@lawinegevaar.nl

[Stanislav Hruška]

I have downloaded packages for Embedeed. There is no engine12.dll in either (32 or 64 b)

Dátum: utorok 30. novembra 2021, čas: 11:08:45 UTC+1, odosielateľ: Stanislav Hruška

[Mark Rotteveel]

On 2021-11-30 11:14, Stanislav Hruška wrote:
> I have downloaded packages for Embedeed. There is no engine12.dll in
> either (32 or 64 b)

Exactly what did you download? For Firebird 3.0 and higher, there no
longer is a separate embedded download.

Mark

[Stanislav Hruška]

It was long time ago. At the beginning. And it's off topic. According to the post, I need engine12.dll 32b and I don't have it.

Dátum: utorok 30. novembra 2021, čas: 11:27:43 UTC+1, odosielateľ: ma...@lawinegevaar.nl

[Mark Rotteveel]

On 2021-11-30 11:08, Stanislav Hruška wrote:
> Thank you for your response.
> I control the basic data. I have been looking for a solution on the
> Internet for a long time. So I know the reason.
> I want to use Embedded. The first time I learn I must to use
> engine12.dll. I have FB 64b installed. Where should I get engine12.dll
> for 32b? Because of this, I do not intend to install FB 3.0.7 32b.
> The fbclient.dll program finds it. And the right version.

You need to download the 32-bit Firebird zip-kit from
https://www.firebirdsql.org/en/firebird-3-0/#Win32

The fact you need engine12.dll is mentioned in the release notes (e.g.
https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rlsnotes30.html#rnfb30-engine-providers),
but you do need to read a bit between the lines. It is also mentioned in
in the Firebird 3.0. Quick Start Guide
(https://www.firebirdsql.org/file/documentation/html/en/firebirddocs/qsg3/firebird-3-quickstartguide.html),
but again, requiring a bit of reading between the lines.

You can also take a look at a blog post I wrote a few years ago (for
using Firebird Embedded with Java, but the basics apply for other
languages):
https://www.lawinegevaar.nl/firebird/jaybird_embedded_example.html

Mark

[Stanislav Hruška]

Hooray, it helped. Thank you very much. A stone fell from my heart.

Dátum: utorok 30. novembra 2021, čas: 11:35:58 UTC+1, odosielateľ: ma...@lawinegevaar.nl

[Ilia Nenashev]

Could you consider adding a more informative exception message for such a case? I have not installed any libraries, trying to connect to a local database just by its file path, and instead of message saying that I need to install a library, I receive this message with some  unexpected strange-looking URL... 

[Mark Rotteveel]

On 09/01/2026 10:15, Ilia Nenashev wrote:
> Could you consider adding a more informative exception message for such
> a case? I have not installed any libraries, trying to connect to a local
> database just by its file path, and instead of message saying that I
> need to install a library, I receive this message with some
> unexpected strange-looking URL...

That is not that simple. The error means that fbclient tried to
establish a local (IPC) connection to the server with XNET, and that
failed because the client cannot connect to the server. The message
itself is not related to embedded at all. You'd get the exact same
message if you had used an explicit XNET URL (e.g. xnet://employee).

Shoehorning a message in there about missing embedded libraries would in
most cases be outright wrong, and IMHO also very confusing. If anything,
maybe a secondary message should be added to inform you to make sure the
Firebird server is running.

Because you don't have plugins/engineXX.dll for the EngineXX provider,
it will not try to create an embedded connection (that provider is
skipped due to its absence), and instead fbclient tries to create a
local connection using XNET (provider Loopback), which then fails
because the server is not running on the current machine, its IpcName is
not FIREBIRD, or the user running the server does not have sufficient
privileges to create the IPC channel in the Global namespace and ISQL is
running in a different session than the server.

I think most people don't expect to use embedded at all; in Firebird 2.5
and earlier (where embedded was a separate download on Windows), a
filename only connection string would in that case also use XNET to the
server. However, back then failure to connect (at least on Windows),
would then result in the very unhelpful message "unavailable database".

That "Unable to complete network request to host [..]" is, by the way,
the same message if you try to establish a TCP/IP connection and the
server is not running, or not listening on the specified port, or
blocked by a firewall.

Mark
--
Mark Rotteveel

[Ilia Nenashev]

When code attempts to perform a requested action, fails, and then tries an alternative, any exception thrown by that workaround should not override the original error. Instead, it should be wrapped with information about the primary failure.
For example, if I try to open a database using a file path and the file cannot be found, I may attempt an alternative connection via a URL. If that also fails, the exception should be reraised and should describe the file-related problem, with additional context such as: “the alternative attempt via URL {URL} also failed: {ERROR}.”

The same applies to embedding or library lookup logic: errors in workarounds should never hide the original problem.

[Mark Rotteveel]

On 09/01/2026 12:31, Ilia Nenashev wrote:
> When code attempts to perform a requested action, fails, and then tries
> an alternative, any exception thrown by that workaround should not
> override the original error. Instead, it should be wrapped with
> information about the primary failure.
> For example, if I try to open a database using a file path and the file
> cannot be found, I may attempt an alternative connection via a URL. If
> that also fails, the exception should be reraised and should describe
> the file-related problem, with additional context such as: “the
> alternative attempt via URL {URL} also failed: {ERROR}.”
>
> The same applies to embedding or library lookup logic: errors in
> workarounds should never hide the original problem.

That is not how the connection providers work: you don't have an
embedded engine, so that provider *is* not even tried: there is no
"previous" error to report.

Not having the embedded engine, and thus establishing an XNET
connection, is the more common case for fbclient.dll used by "normal"
applications that only provide a filename as the connection string,
because applications usually load an fbclient.dll that does not have an
embedded engine (e.g. from %WINDIR%\System32, or from their own folder).

That is the longstanding behaviour on Windows, dating back to at least
Firebird 1.0. The fact that since Firebird 3.0 fbclient first tries
embedded if it has access to the engine plugin instead of *always*
connecting through the server for filename only connection string can
actually be problematic in some cases (especially if ServerMode is the
default of Super).

Reporting messages about requiring the embedded engine, when that is
*not* the common case, and generally not expected would do more harm
than good.

If you had explicitly configured fbclient.dll to only try the embedded
engine (i.e. setting `Providers = EngineXX` in firebird.conf of the
client), you would have only received the error "unavailable database"
if it didn't actually have access to the engine plugin, because then it
would have tried *no* providers at all (which is a case which actually
might need a better message than just "unavailable database").

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-support wrote 09.01.2026 12:48:
> That is not how the connection providers work: you don't have an embedded
> engine, so that provider *is* not even tried: there is no "previous" error to
> report.

In this case "previous error" is plugin loading error which can provide a
valuable hint for troubleshooting.

The only problem is the capacity of ISC API status vector.

--
WBR, SD.

[Mark Rotteveel]

On 09/01/2026 12:58, 'Dimitry Sibiryakov' via firebird-support wrote:
> 'Mark Rotteveel' via firebird-support wrote 09.01.2026 12:48:
>> That is not how the connection providers work: you don't have an
>> embedded engine, so that provider *is* not even tried: there is no
>> "previous" error to report.
>
>   In this case "previous error" is plugin loading error which can
> provide a valuable hint for troubleshooting.

The common case is that fbclient.dll is *not* able to load the EngineXX
provider, so reporting errors about its failure to be loaded for any
local (filename only) connection failure will in general obscure the
real problem and cause confusion, and would not be helpful for those
more common cases.

BTW: I'd assume that fbclient tries to load a provider only once, on
first use, and not for each connection attempt (within the same
process). If so, the error reporting would then probably become
inconsistent, as subsequent connection attempts would not have attempted
to load it, and thus have no error to report.

The error reported could probably be improved by providing some
troubleshooting suggestions, and/or reporting the actual provider that
was tried (Loopback), but focusing on improving it for the IMHO
exceptional case of expecting embedded is not it.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-support wrote 09.01.2026 13:20:
>
> The common case is that fbclient.dll is *not* able to load the EngineXX
> provider, so reporting errors about its failure to be loaded for any local
> (filename only) connection failure will in general obscure the real problem and
> cause confusion, and would not be helpful for those more common cases.

That's why embedded plugin had to be removed from the default list years ago.

> BTW: I'd assume that fbclient tries to load a provider only once, on first use,
> and not for each connection attempt (within the same process). If so, the error
> reporting would then probably become inconsistent, as subsequent connection
> attempts would not have attempted to load it, and thus have no error to report.

Your assumption is wrong.

--
WBR, SD.

[Mark Rotteveel]

On 09/01/2026 13:43, 'Dimitry Sibiryakov' via firebird-support wrote:
> 'Mark Rotteveel' via firebird-support wrote 09.01.2026 13:20:
>>
>> The common case is that fbclient.dll is *not* able to load the
>> EngineXX provider, so reporting errors about its failure to be loaded
>> for any local (filename only) connection failure will in general
>> obscure the real problem and cause confusion, and would not be helpful
>> for those more common cases.
>
>   That's why embedded plugin had to be removed from the default list
> years ago.

Do you mean "should have been"? Because it wasn't removed, which "had to
be" implies. In any case, that ship has now sailed.

There are other problems given the lack of separation of
responsibilities with firebird.conf configuring both the server process
and fbclient.dll, using the same properties (Providers in this specific
case).

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-support wrote 09.01.2026 13:51:
> There are other problems given the lack of separation of responsibilities with
> firebird.conf configuring both the server process and fbclient.dll, using the
> same properties (Providers in this specific case).

Yes, this is just another feature that was never properly completed.

BTW, "Providers" is not the case: it has nothing to do with server executable
and controls only behavior of fbclient library.

--
WBR, SD.

[Mark Rotteveel]

It also controls server behaviour: say you want your Firebird 5 server
to connect to a Firebird 3 database, you need to add Engine12 to
Providers. AFAIK, only Remote is skipped server-side.

Adding engine12.dll to plugins is not sufficient, it must be set in
Providers, either in firebird.conf, or in databases.conf for that
specific database.

In other words, Providers is used both by client and by server.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-support wrote 09.01.2026 14:22:
> It also controls server behaviour: say you want your Firebird 5 server to
> connect to a Firebird 3 database, you need to add Engine12 to Providers. AFAIK,
> only Remote is skipped server-side.

Yes, and as soon as you do it, you'll get embedded access to Firebird 3
databases as well.

> Adding engine12.dll to plugins is not sufficient, it must be set in Providers,
> either in firebird.conf, or in databases.conf for that specific database.

Yes, but this has nothing to do with server executable. Both databases.conf
and Providers setting in firebird.conf are used exclusively by fbclient.dll.

> In other words, Providers is used both by client and by server.

Or more precisely, fbclient.dll is used by both client (it IS client) and
server. And this is a part of problem.

--
WBR, SD.

[Mark Rotteveel]

On 09/01/2026 14:28, 'Dimitry Sibiryakov' via firebird-support wrote:
>   Yes, but this has nothing to do with server executable. Both
> databases.conf and Providers setting in firebird.conf are used
> exclusively by fbclient.dll.

And that means it configures the server: which providers *the server*
tries to open a database.

Mark

--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-support wrote 09.01.2026 14:31:
>>    Yes, but this has nothing to do with server executable. Both databases.conf
>> and Providers setting in firebird.conf are used exclusively by fbclient.dll.
>
> And that means it configures the server: which providers *the server* tries to
> open a database.

No. The server just use the client to open databases. It neither read
Providers setting from firebird.conf nor set it via DPB (except security database).
Though firebird.conf is a single configuration file, different settings from
it are read by fbclient.dll, firebird.exe and engineXX.dll independently.

If at the time of version 3 transition from 2.5 config had been complete,
server would provide a separate configuration to fbclient.dll for usage inside
of server process. But it wasn't done (still may happen in the future if pull
request are accepted more frequently).

--
WBR, SD.

[Mark Rotteveel]

On 09/01/2026 14:42, 'Dimitry Sibiryakov' via firebird-support wrote:
> 'Mark Rotteveel' via firebird-support wrote 09.01.2026 14:31:
>>>    Yes, but this has nothing to do with server executable. Both
>>> databases.conf and Providers setting in firebird.conf are used
>>> exclusively by fbclient.dll.
>>
>> And that means it configures the server: which providers *the server*
>> tries to open a database.
>
>   No. The server just use the client to open databases. It neither read
> Providers setting from firebird.conf nor set it via DPB (except security
> database).
>   Though firebird.conf is a single configuration file, different
> settings from it are read by fbclient.dll, firebird.exe and engineXX.dll
> independently.

You are talking about the actual implementation, I'm talking about the
observable effect.

Mark
--
Mark Rotteveel

[Florian Hector]

Hi,

I have a very strange problem on my development PC running Windows 10:

There are two Firebird installations, FB3 and FB4.
Both versions were not installed but simply unpacked from the ZIP files into separate directories,
the services were installed using the install_service batch file with the parameter FB3 and FB4
respectively.

FB3 is set to listen at port 3060, FB4 listens at port 3070.

Now, when FB3 is started, it listens at port 3070, a subsequent start of FB4 fails with an entry in
firebird.log saying that the port is already in use.
Even reinstalling FB3 does not change the behavior described.

I have searched for orphan conf files, checked the services file, all to no avail.

Any help welcome

Florian

[Dimitry Sibiryakov]

Florian Hector wrote 09.01.2026 15:21:
> the services were installed using the install_service batch file

That was the mistake. This batch file unnecessary call `instreg` utility
which spoils configuration search path for both versions so they both are
looking at the same firebird.conf.
Run `instreg u` to erase registry settings.

--
WBR, SD.

[Florian Hector]

Thank you very much, that helped

F.