IBX 2.3.2 is now available for download

[tonyw]

Well, I've looked at the changelog and code diffs and can't see anything obvious that could cause a a SIGSERV. Not very much has changed in this area apart from tidying up how starttransaction behaves for single database connection versus multiple database connections - and I can't see how that could affect his.

I believe the most likely reason is an out of step error, especially if you have not removed an earlier version o IBX.

The Lazarus IDE is very sticky when it comes to package references and I am just wondering if you are compiling IBX 2.3.3 using the old version of the low level fbintf package. The way to test this is to open the new package (i.e. ibx/fbintf.lpk) in the iDE before compiling your program with IBX 2.3.3. That will make the IDE choose the new version over the old.

[gerardus]

I shall have a look at it as soon as I have some time, in a clean VM with a fresh Lazarus install.
But I'm pretty sure last time I removed  everything, making sure that I couldn't compile my programs before reinstalling  the 2.3.3 package.

[Zoran]

Hello, Tony
I just checked out the trunk version of IBX and there is a problem currently with package fbintf -- the paths are broken (open fbintf in Lazarus' package editor and you'll see that it cannot see the files).

In 2.3.3, the paths are correct.
I'm attaching the snapshots, comparing trunk and 2.3.3 package options. In trunk version the paths should be prefixed with "fbintf\", like they are in 2.3.3.

EDIT:
Now I see that not only paths listed in "other unit files" edit box (which I surrounded in red) are wrong, but also paths in "include files", as well as "unit output directory". This can be also seen on attached screenshot.

[Zoran]

Sorry, I was too fast.
Not enough, actually, just to change paths.
The files were moved, reorganized, so should be added again to the package, one by one.

[tonyw]

Apologies. Looks like a step was missing in the script that performed the last update.

The correct version of fbintf.lpk is now available in trunk

[Zoran]

Thank you, Tony.

[Zoran]

Hello, Tony,

I think that IBX's strategy of finding the client library path should be changed.

Please allow me to explain my today's experience:

On my Windows 7 computer, I just couldn't make IBDatabase connect.
I tried on Linux and had no problems. I tried on another computer with Windows, and it also just worked without problems.

Both these Windows machines have the same FB version installed, both have fbclient.dll of the same version (3.0.4) in System32 directory.

On both machines, FlameRobin connects without problems.
On both machines other libraries in Lazarus (I tried SQLdb and Zeos) connect without problems.

I had no idea what it could be, then, I tried to give client dll path expicitely, and I was surprised that it worked:

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button1Click(Sender: TObject);
2. begin
3.   // Only with this line, the connection was succesfull:
4.   IBDatabase1.FirebirdLibraryPathName := 'C:\Windows\System32\FBCLIENT.DLL';
5.  
6.   IBDatabase1.DatabaseName := 'localhost/3053:employee';
7.  
8.   IBDatabase1.Params.Values['lc_ctype'] := 'UTF8';
9.   IBDatabase1.Params.Values['user_name'] := 'sysdba';
10.   IBDatabase1.Params.Values['password'] := 'masterkey';
11.  
12.   IBDatabase1.Connected := True;
13. end;
14.  

However, I know that, if IBX didn't see any client library, the components would not appear in component palette at all. Hence, it does see it.

Then I found it -- apart from FB 3.0.4, I have FB 2.5 engine installed on same machine. They use different ports.
What should matter is that the client library installed in system directory is fbclient 3.0.4.

However, there was still fbclient.dll 2.5 inside folder where FB 2.5 engine is installed. When I removed it, everything started to work, without setting the client path explicitely.

Yes, the old FB 2.5 engine is installed in default location (C:\Program files\Firebird\... etc.), and FB 3.0 is not, but that should not matter. The two services listen to different ports, and again, only newer client is installed in system folder, which is why other client utilities make their connections through it.

I could accept that the application's folder might have priority over system folder (and that is still questionable, if a programmer wants to distribute client library in application folder, he knows what he is doing and he can set FirebirdLibraryName to current directory in code).

Anyway, I strongly believe that client library which is installed in system folder must have priority over default installation folder of FB engine.

My customer could even have older Firebird server installed on current machine, but want to connect to different server which has newer FB engine. He should just install newer client, no need to touch his old server installation -- newer client library connects to older server, but the older cannot connect to new FB engine.

Don't you agree?

[tonyw]

Zoran,

"DLL Hell" is one of the many pleasures(?) of using Windows. As you noted, things are just so much simpler under Linux. I first published about 15+ years ago the algorithm used by IBX to locate the FBCiient library under Windows and it's documented in the "Firebird Pascal API Guide" in section 3.2.2.

Briefly, the algorithm first looks in the installation folder. This is because installing the Firebird Client library along with the application follows MS guidelines (my understanding) and is the best way to avoid stealth upgrades and downgrades. This is the first action because this is what you expect in a production system.

The alogrithm next checks the registry. If Firebird has been installed using one of the official installers, then the registry key is set to the Firebird installation directory and that's where IBX will look next. This is typical of a development system where a Firebird Server has been installed alongside Lazarus and you want it available to all of your development applications.

After that you are really more into trying to get something to work in a broken system where Firebird has not been correctly installed. IBX checks well known installation folders, and then only then tries use the PATH variable. This is when it will find FBCLIENT.DLL if it is in "System32". Finally, in desperation, IBX looks for "gds32.dll". I assume that in your case, it picked up the Firebird 2.5 client DLL because it was in a well known location. Flamerobin probably skips this step.

"System32" is a bad place to locate any third party DLL. I'm sure I recall Microsoft advising against it. There are, for example, no naming conventions to make sure that someone else doesn't come along and over-write your DLL with a totally different one.

The good news is that as you observed, IBX does allow you to explcitly specify which FBClient.DLL you want when the one you want is not the one returned by the search algorithm. However, I do believe that the correct sequence is:

1. Installation folder (production systems)

2. Folder given by Firebird Registry Key (development systems).

3. Go though well known Firebird installation folders in order of Firebird 3 and downwards.

4. Finally use the PATH.

5. Give up and assume InterBase

The last three are really for non-standard installations and undofrunately, IBX cannot always second guess what you intend.

[Zoran]

Thank you, for thorough answer.

[incendio]

Hi guys,

I tried IBX 2.3.3 on Lazarus 2.0.2 on Linux Mint 19.1.

The Project file was a modified version of multi threading example from Lazarus.

When Step Over the project (pressed F8), got an error :
The file build/glibc-otsel5/glibc-2.27/elf/dl-error-skeleton.c was not found.

The codes is something like this

Code: Pascal  [Select][+][-]

1. // on Datamodule unit, class name DtM
2. type
3. Conn1: TIBDatabase;
4. Q5: TIBQuery;
5.  
6. // On MainUnit.Pas
7. DtM.Conn1.Close;
8. DtM.Conn1.Open
9. DtM.Q5.Close;
10. DtM.Q5.SQL.Clear;
11. DtM.Q5.SQL.Add('.....');
12. DtM.Q5.Open;
13.  

Error when DtM.Conn1.Open called. On Database Editor, test connection on Conn1 was succesfull.

Without Step Over, project runs OK.

So is this error from IBX or Lazarus?

Edited Jun,17,2019
This is not IBX problem, most likely it is from Lazarus.

[Zoran]

Hello, Tony,

I remember that for a short period there used to be the bugtracker on mwa site, but it dissappeared after a while.
Would you think about the "official" place where IBX should be discussed?
Instead of maintaing the bugtracker yourself, you might ask for a subforum in Lazarus forum, like some other libraries have. Probaby, a dedicated subforum here would be more suitable for IBX.

For example, TAChart, BGRA have their place under Graphics; then, fpspreadsheet, RichMemo have their subforums under Packages and Libraries.
For these libraries, this is the right place for asking questions and reporting bugs.

IBX is a big library, have been actively developed and maintained for several years already.
I don't know if there are some conditions that need to be satisfied for getting the subforum, but surely IBX has significance for FPC/Lazarus community which is not smaller than significance of some other libraries which have its own subforums, so in my opinion it deserves its own place here.
It could be placed either under Packages and Libraries or under Databases.

What do you think?

[Zoran]

So is this error from IBX or Lazarus?

I think that there is more that you can do yourself before asking community:

First, try the same with SQLdb controls instead of IBX. Does the same problem appear?
If the answer is yes, then this is FPC or Lazarus problem and should be reported to the bugtracker.

If not, then prepare the application which shows the problem, as simple as possible. Upload this sample application here, instead of just code snippets. Tony will surely try to answer this eventually, but please first you try to do your best to help debugging.

[zoltanleo]

Hello, Tony

Thank you for developing your components. And special thanks for giving the user the opportunity to freely choose the server client library. I have been waiting for this for a very very long time 

Now I'm trying to use your components again (from OPM for laz r61706).

In my OS (Windows 7), several 32-bit FB servers are launched as applications (e.g.  "D:\Portable_program\Firebird_server\Firebird_2_1_7\bin\fbserver.exe" -a -p 3217). I'm trying to create a simple database connection with this code:

Code: Pascal  [Select][+][-]

1. const
2.   DBName: String = 'localhost/3217:D:\Archive\Databases\general_base\GENERAL_BASE_1903_25.FDB';
3.   ClientLib: String = 'd:\Portable_program\Firebird_server\Firebird_2_1_7\bin\fbclient.dll';
4. begin
5.   with IBDatabase1 do
6.   begin
7.     DatabaseName:= DBName;
8.     FirebirdLibraryPathName:= ClientLib;
9.     Params.Add('user_name=SYSDBA');
10.     Params.Add('password=cooladmin');
11.     Params.Add('lc_ctype=WIN1251');
12.     LoginPrompt:= False;
13.   end;
14.   try
15.     IBDatabase1.Connected:= True;
16.   except
17.     on E:EIBInterBaseError do
18.     begin
19.       ShowMessage(e.Message);
20.       IBDatabase1.Connected:= False;
21.     end;
22.   end;
23.  
24.   if IBDatabase1.Connected
25.     then
26.       Self.Caption:= 'Connection on'
27.     else
28.       Self.Caption:= 'Connection off';
29. end;

сauses a connection error 

Project project1 raised exception class 'EIBInterBaseError' with message:
Your user name and password are not defined. Ask your database administrator to set up a Firebird login

In file 'D:\Archive\development\lazarus_21_r61706_ibxlaz\_config\onlinepackagemanager\packages\ibx\runtime\nongui\IBDatabase.pas' at line 1141

If you change the connection string and the client library (e.g. for FB 3.0.4.)

Code: Pascal  [Select][+][-]

1. DBName: String = 'inet4://127.0.0.1:3304/D:\Archive\code_source\bases\ARMDOC_5000_UNICODE_FB3.FDB';
2. ClientLib: String = 'D:\Portable_program\Firebird_server\Firebird_3_0_4\fbclient.dll';
3. ...
4. Params.Add('lc_ctype=UTF8');
5. ...

then connection errors do not occur.

At the same time, the same connection parameters in IBExpert do not cause any error (see both screenshots for each case).

Can you comment on this situation?

UPDATE: Obviously, the "old" IBX packages are in the OPM repositories. I installed IBX r.288 and the error went away.

Thank you again for developing the component.

[Vingadero]

Hello,

I got this version to test and noticed that the "Modified" property is not setting to true after making a change to an TDBEdit component.

Code: Pascal  [Select][+][-]

1. if DBEditID.Modified then
2. begin
3.   ...
4. end;

Also the OldValue and NewValue of TField get always the last value.

Code: Pascal  [Select][+][-]

1. if DBEditID.Field.OldValue <> DBEditID.Field.NewValue then
2. begin
3.  ...
4. end;

I'm usung Lazarus 2.0.4 and IBX 2.3.2 (tried 2.3.3 from site and got same issues).

****EDIT: Just to know, on IBX 2.0-3 it's works perfectly ****

Best Regards