I started a new message thread, as it doesn't really relate to the
origin thread any more.
On 17/08/12 06:50, LacaK wrote:
> BTW: packages/ibase is intended to be translation of Firebird client
> API not Interbase, right ?
Yeah, the unit naming scheme is a bit dodgy at the moment. At one point
in history (Firebird v1.x days) the two products, Firebird and
Interbase, were similar, thus the combined header translation unit. But
yes, their development paths have diverged, supporting different
features, using different client libraries etc.
So really the SqlDB code should probably be split into Interbase support
and another unit for Firebird support. I know Firebird did try and stay
Interbase API compatible in the v1.x days, but I don't know if that is
still true in v2.5+ days. Anybody have more detailed info on this? I
can add that I have a commercial database design tool that I use, and
when generating DDL from my designs, there is a Interbase option and a
Firebird option - so clearly enough has changed in the last 10 years to
consider them separate products now.
On 17-8-2012 11:47, Graeme Geldenhuys wrote:
> I started a new message thread, as it doesn't really relate to the
> origin thread any more.
> On 17/08/12 06:50, LacaK wrote:
>> BTW: packages/ibase is intended to be translation of Firebird client >
> API not Interbase, right ?
AFAIK, it's intended to be both Interbase 6+ and Firebird 1+.
Once again, AFAIK, there have been no big changes in the sqldb IB code
in ages. Even my recent patch to improve BLOB performance corrected
ancient pre-IB6 era API handling.
Practical suggested solution: I'd split out the current code and stamp
it IB6+, let anybody interested deal with it.
Then the FB code can focus on Firebird.
See below for more details.
I've never heard of anybody using it with Interbase (or, more
positively, of anybody having any problems with it and Interbase).
Interbase and Firebird features have indeed since diverged. I.e.
apparently Interbase has had support for boolean datatype for a while
now, while as you and I mentioned in the other thread, FB3 will start to
The way boolean supported probably differs; I don't use interbase though
so couldn't say. There are other changes; apparently IB has encryption
As for Firebird 2: there have been some more built-in SQL function
keywords over the years, optimizer changes etc... by heart, nothing that
should really influence sqldb.
Perhaps there are changes though that can be applied; given FB's great
backward compatibility we might be sending inefficient stuff over the
wire/not support new features I've forgotten.
There have been changes in the Services API; Ludo's recently added unit
AFAIK targets FB 2.x (works on my tests with 2.5).
IIRC Firebird 3 will have modular encryption of the traffic between
client and server, boolean datatype, support for stored procedures in
external languages (Java, C++, who knows, perhaps FreePascal).. though
whether the latter will require different driver code at the FPC end, I
As for splitting up the units: presumably it would make sense to split
FB and IB. We can leave the current IB6 era functionality for IB and let
anybody interested update that.
Regarding FB2/FB3, FYI please note this snippet in the other thread: my
post and Michael's reply:
>> OT: that would be useful for another reason.
>> Firebird 3 will introduce the BOOLEAN datatype and other innovations
>> (encrypted connections, etc).
>> Interbase has had BOOLEAN support for a while now.
>> It would be nice to be able to support new functionality without
>> sacrificing the ability to connect to older clients.
> That has nothing to do with dyn versus static linking.
> You can perfectly detect which library version you are loading, and enable/disable certain functions based on this.
> Regarding FB2/FB3, FYI please note this snippet in the other thread: my
> post and Michael's reply:
>>> OT: that would be useful for another reason.
>>> Firebird 3 will introduce the BOOLEAN datatype and other innovations
>>> (encrypted connections, etc).
>>> Interbase has had BOOLEAN support for a while now.
>>> It would be nice to be able to support new functionality without
>>> sacrificing the ability to connect to older clients.
To be concrete: take as example BOOLEAN datat type:
#define SQL_BOOLEAN 32764 // new in Firebird 3.0
#define SQL_NULL 32766 // new in Firebird 2.5
Interbase 7.0 (For ESQL and DSQL programmers, we define the following
type in ibase.h:):
#define SQL_BOOLEAN 590 ... ;-))
So how we should update ibase60.inc ?
Add both ? (SQL_BOOLEAN_INTERBASE=590, SQL_BOOLEAN_FIREBIRD=32764 ...
and support both in one TIBConnection ... I expect, that data will be in
both cases as 0/1 signed short ) ... it seems to me easier!
Or split header files ... but then we must also create TFBConnection
(like TIBConnection) ? ... it seems to me more complicated ATM