IBC "forgets" server data

Discussion of open issues, suggestions and bugs regarding IBDAC (InterBase Data Access Components) for Delphi, C++Builder, Lazarus (and FPC)
Post Reply
michaschumann
Posts: 44
Joined: Fri 14 Nov 2014 15:26

IBC "forgets" server data

Post by michaschumann » Fri 03 Feb 2017 11:43

Hello,

as a follow up to my post some time ago I now baught the IBDac source and compiled my application with debug data in those units too. As I use a modified JCL Exception dialog that shows the stack dump I could find the position in IBC where the mysterious thing happens and output some interesting data:

The client connects to 10.10.10.45/1709:d:\Programme\itcemil\emil.fdb25 (Firebird 2.5). 99% of the cases it works well. The remaining 1% the following thing happens:

I/O error during "CreateFile (open)" operation for file "D:\PROGRAMME\ITCEMIL\EMIL.FDB25"
Error while trying to open file
Das System kann den angegebenen Pfad nicht finden.
Fehlerklasse: EIBCError


This happens if I use the embedded client, a differend error occurs if I use the "normal" client. According to the Firebird documentation the embedded client is suitable for server connections. For 15 years I have been using the embedded client now without problems.

I tracked down the error to the following position and added some lines to your source to display the connection string used:

Code: Select all

IBCClasses.TGDSConnection.IBCError (Line 1728, "IBCClasses.pas" + 10)
IBCClasses.TGDSConnection.Check (Line 1709, "IBCClasses.pas" + 2)
IBCClasses.TGDSConnection.Connect (Line 2092, "IBCClasses.pas" + 42)
DBAccess.TCustomDAConnection.DoConnect (Line 4076, "DBAccess.pas" + 16)
IBC.TIBCConnection.DoConnect (Line 1961, "IBC.pas" + 7)
DBAccess.TCustomDAConnection.PerformConnect (Line 4192, "DBAccess.pas" + 8)
DBAccess.TCustomDAConnection.SetConnected (Line 5245, "DBAccess.pas" + 109)
DBAccess.TCustomDAConnection.Connect (Line 4169, "DBAccess.pas" + 1)
DBAccess.TCustomDAConnection.InternalConnect (Line 4139, "DBAccess.pas" + 7)
DBAccess.TCustomDADataSet.BeginConnection (Line 7629, "DBAccess.pas" + 14)
DBAccess.TCustomDADataSet.Execute (Line 8190, "DBAccess.pas" + 9)
DBAccess.TCustomDADataSet.Execute (Line 8173, "DBAccess.pas" + 1)
uPatOpenFile.TpatOpenFile.FormCreate (Line 216, "uPatOpenFile.pas" + 37)
It is important to mention that the code of uPatOpenFile.TpatOpenFile.FormCreate cannot be reached before the (only) TConnection Object is already connected as a lot of initialisation runs first and reads from the database. So somehow at this place a reconnect occurs. The things I execute are simple queries.

Here is the modification I made from Line 2073 on in IBClasses.pas, ErrConnectInfo is a global variable in this unit that is read by my Exception dialog.

Code: Select all

try
      GDS.Busy;
      try
        ErrConnectInfo := 'GDS.isc_attach_database: ' + FullDBName + ' (' + Encoding.
          Default.GetString(FullDBNameB) + ') = ';
        Res := GDS.isc_attach_database(FStatusVector, Length(FullDBNameB), FullDBNameB, FDatabaseHandle,
        FDPBLength, {$IFDEF FPC}PChar{$ENDIF}(FDPB));
        if Res <> 0 then
        begin
          try
            ErrorNumber := Marshal.ReadInt32(FStatusVector, 1 * SizeOf(NativeInt));
          except
            ErrorNumber := -9999;
          end;
          ErrConnectInfo := ErrConnectInfo + IntToStr(Res) + ' - ' + IntToStr(ErrorNumber);
        end;
      finally
        GDS.Release;
      end;
And - the mystery: When this exception occurs IBC definitively forgets the server information as ErrConnectInfo then contains:

GDS.isc_attach_database: d:\Programme\itcemil\emil.fdb25 (d:\Programme\itcemil\emil.fdb25) = 335544344 - 335544344

Somehow FullDBName strips off the Server information. So I think there must be some Error in IBC (also Unidac as it also happened with unidac).

Please help! I cannot supply a reproducable example as this is a sporadic error but I think this is evidence enough that the server information gets lost within IBDac and it has nothing to do with the client.

Thanks,

Michael

ViktorV
Devart Team
Posts: 3168
Joined: Wed 30 Jul 2014 07:16

Re: IBC "forgets" server data

Post by ViktorV » Fri 03 Feb 2017 13:01

As we wrote earlier, unfortunately, we could not reproduce the issue. To understand its cause and find a solution to fix it, we need a test sample in which the issue consistently reproduced. As soon as we receive this sample and if the cause of the issue is in our product's code, we will try in the shortest time to fix it.
But, as you have IBDAC source code, you can find the cause of this error occurrence. For this you can use the following guidelines:
- as the error cause is that the FullDBName variable is set to an empty string - this can only happen in the GetFullDatabaseName method when the FServer field is an empty string;
- this field can be set only by using the TCRConnection.SetServer method declared in the module CRAccess.pas;
- in the TCRConnection.SetServer method you should generate exception when the Value parameter is an empty string and then you can determine the cause of its setting according to the stack.

michaschumann
Posts: 44
Joined: Fri 14 Nov 2014 15:26

Re: IBC "forgets" server data

Post by michaschumann » Fri 03 Feb 2017 16:13

Thanks for the Tipps. I will monitor the SetServer procedure and see when it happens.

ViktorV
Devart Team
Posts: 3168
Joined: Wed 30 Jul 2014 07:16

Re: IBC "forgets" server data

Post by ViktorV » Mon 06 Feb 2017 08:18

When you get any results concerning this question, please let us know.

michaschumann
Posts: 44
Joined: Fri 14 Nov 2014 15:26

Re: IBC "forgets" server data

Post by michaschumann » Mon 03 Apr 2017 12:45

It was some buggy code in a background thread that confused IBDac. This code also caused other sporadic problems. Through this error I finally found the buggy code and removed it.

Facit: No error in IBDac, my own fault.

ViktorV
Devart Team
Posts: 3168
Joined: Wed 30 Jul 2014 07:16

Re: IBC "forgets" server data

Post by ViktorV » Wed 05 Apr 2017 07:58

It is good to see that the problem has been solved.
Feel free to contact us if you have any further questions about our products.

Post Reply