Hello Geoff,

> > I just found out that by default, the new IBO will load
> > fbclient.dll (if it can find it) over gds32.dll (the old
> > behaviour).
>
> I think this one is probably my fault, being part of some
> changes that I sent to Jason to allow changing of the client
> library at runtime. There are really two parts to this.
>
>
> 1. The decision to use a function ptr global instead of having
> users change the old library constant/variable.
>
> The IB_GetClentLibName function ptr variable should be used
> in preference to changing the library name "constants".
>
> To use it...
>
> program
> MyProgram;
> uses
> Forms,
> IB_Session, // Must use IB_Session
> // etc
> ;
>
> function GetFBClientLibName: string;
> begin
> Result := 'myfbclient.dll';
> end;
>
> begin
> // Tell IB_Session where to get the client lib name
> IB_GetClientLibNameFunc := GetFBClientLibName;
> // then continue with the normal stuff
> Application.Initialize;
> // etc
> end.
>
> Why is this better than changing the "constant"? Because it
> becomes possible to have the client library dynamically load
> and unload as needed - and so also provides the potential to
> write programs that switch between using different libraries
> (one at a time). Without having to time when to change the
> "constant" variable.
>
> In the future Jason may also find ways of allowing different
> session instances to use different libraries. A function
> is better placed to support such functionality (although
> whether its signature may need to change to take a parameter
> or two is unclear at the moment).
>
>
> 2. The choice of which "default" client library name to try
> first when no specific client library has been specified.
>
> The choice to do one or the other first is pretty arbitrary
> really. I chose Firebird because thats what I use and I
> find it hard to imagine ever wanting Interbase - so I save
> a couple of clock cycles by doing it first, and save having
> to create gds32.dll in a Firebird installation.
>
> Which ever is chosen as the arbitrary first/default library
> name, you are already in a precarious situation if you have
> incompatible versions of both fbclient.dll and gds32.dll
> available in your path.
>
> > This can cause weird errors, like in my situation, after
> > the IBO upgrade, my application tried complaining about a
> > wrong ODS version because it was connecting to Firebird
> > instead of InterBase.
>
> How is this any different to the reverse situation that seems
> just as likely? How is attempting gds32.dll first going to
> help or make anything more reliable?

Well, for one reason, this behaviour changes the default
(gds32.dll) and therefore is not backwards compatible.

I don't know if you read the discussion about silently
ignore strings that are too long? IMO, that was a much
greater error, as it silently changes the data (by default)
that goes into your database. To my amazement, this
was behaviour that was "wanted" by the people who
replied.

Jason went through some (small) loops to create a property
to turn this behaviour OFF and keeping the current (IMO,
faulty) behaviour as default because of backwards compatibility
reasons. Fine.

Guess what, now there's another change that does exactly
the opposite: change the default behaviour.

This is why I'm reasing this point in this list.

> Short of holding a poll to indicate numbers of IB vs FB users
> it is impossible to tell if there should be any overall
> preference (ideally the most commonly used should be the
> first one tried). If Jason wants to reverse the order then
> that is fine with me, but it seems to me that your problems
> are symptomatic of larger installation issues.

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com