Unidac/Firebird Server ignored?

[michaschumann]

One of my customers very often receives an error with Unidac (one of the latest versions) after relocation the application to an other server called "ei-app":

I/O error during "CreateFile (open)" operation for file "d:\programme\itcemil\emil.fdb"
Error while trying to open file

The connection string is "ei-app:d:\programme\itcemil\emil.fdb".

As firebird creates a different error message if the database file cannot be accessed and other stations are connected to the same database at the moment the error occurs it looks to me as if unidac DB-Connection sometimes ignores the server part of the connection string and tries to connect locally - the file of course is not present on the users machine.

Did anyone else also experience this error?

[ViktorV]

To solve the issue, please specify a path to a client library in the TUniConnection.SpecificOptions.Values['Clientlibrary'] property. Please make sure that the client library version of Firebird corresponds to the server version you use and check correct writing of the database location path on the server like this DriveLetter:\filesystem-path\database-file.
If this does not help in solving the issue, in the TUniConnection.Server property specify the IP address of Firebird, but not its domain name.
Please follow our recommendations and inform us about the result.

[michaschumann]

Thanks for the advice. I already informed customers IT department to use the IP address instead of the server name, I have no feedback yet. Regarding the client library I have been using the embedded Client 2.5.6 on Firebird 1.5.6 (client/server) for quite some time without any problems. Can this be a real problem?

[ViktorV]

Using embedded Firebird client library can be a reason of this issue occurrence. Therefore, please use Firebird client library which corresponds to the server version that you use.

[michaschumann]

We replaced the server name by the IP address but the problem sporadically still occurs.

We have been using the embedded server as client library for more than 10 years and never ran into problems. For some reason (I currently do not remember) we chose to use the 2.5 client against firebird 1.5.6 a few years ago (maybe stability or whatever). Also the problem first occured a few weeks ago in an installation that was relocated onto a 2012er server. This makes me believe that the cause cannot be the fact of using the embedded client or a newer version of the firebird client. Is it possible that an environment setting can confuse unidac?

By the way, we store the client in an application subdirectory and make the UNIConnection know the location of the dll. The root directory for client and embedded server is always the location of the fbclient/fbembed dll, isnt it?

[ViktorV]

Unfortunately, we could not reproduce the issue.
In order to get a detailed answer, please compose a small sample demonstrating the described behavior and send it using the contact form https://www.devart.com/company/contactform.html including scripts for creating database objects. Also please specify the exact client library version and the environment (OS version) where it is used and also the exact version of Firebird server and the environment (OS version) where it is installed.

[michaschumann]

As this issue is sporasic but now happens with more and more customers without their software being updates I suspect something that is caused by windows updates.

One question: I had "force client unload" active for some reason in the firebird specific settings. What does this setting do?

[ViktorV]

This option was introduced to prevent AV occurrence when trying to upload fbembed.dll if before this there was an attempt to connect to any remote server via a network protocol using it. More detailed information about the reason of its addition you can find in your topic on our forum: viewtopic.php?t=31807

[michaschumann]

I now use the fbclient.dll V 156 against 1.5x servers and hopefully the problem goes away. I will post the results of the next weeks...

[michaschumann]

Hello,

unfortunately this all did not help. I now use the 1.5.6 Client againts a 1.5.6 Database server and instead of the embedded server trying to connect to the database file locally now the client throws the error "unavailable database".

This happens from time to time, some workstations have massive problems, some not. And its mostly with one customer who changed to Server 2012 but others experience it also from time to time. It ainly happens when a simple Query component from the data module is used by assigning the sql property as text and then opened.

That's why I believe it has to do with the reconnect feature I once activated and what solved quite some problems in instable networks. I suspect that unidac does somewho "forget" the server setting when reconnecting after connection lost. Perhaps I did not set it up correctly.

My DBConnection has the following settings on:

AllowImplicitConnect, DIsconnectedMode, LocalFailover.

And only one event is connected: OnConnectionLost with RetryMode := rmReconnectExecute;.

Is this the correct way to deal with reconnects?

[ViktorV]

Yes, to restore a lost connection you use the event handler TUniConnection.OnConnectionLost correctly.
Note, Unidac does not automatically initiate a connection check with the server. Therefore, after a successful connection to the server if the connection to the server breaks the TUniConnection.Connected property will be set to True and the OnConnectionLost event does not occur until there is a request attempt to the server.

[michaschumann]

OK, thanks for your reply.

As the problem does suddenly occur while working with the application I see only connection loss as reason for the trouble. That would also explain why some customers exterience it from time to time, one extremely often and some never.

To verify this suspicion I will store the complete database settings on first connect and reapply them in OnConnectionLost. Ist this possible or will the DB component still be connected at this time?

[ViktorV]

The event OnConnectionLost handling is aimed for a possibility to reconnect to the server which lost a connection and to restart the operations in its environment. Therefore, setting new connection properties will be ignored in the OnConnectionLost event handler.

[michaschumann]

So is there a chance to find out, why the connection sudenly seems to forget the server setting? Is there a chance to do any diagnostic perhaps in reconnect to find the reason?

As it seems to be completely independant of the client dll (changing to the normal client in Version 1.56 did not make any difference compared to the embeddeb 2.56 Server) It must be located somewhere in Unidac? Perhaps a wrong connection parameter?

[ViktorV]

As we wrote earlier, unfortunately, we could not reproduce the issue. To understand the issue cause and to find a solution to fix it, we need a test sample where the issue is consistently reproduced. As soon as we receive this sample and if the cause of the problem is in UniDAC code, we will try to to fix it as soon as possible.