| Subject | Firebird 2.x and old IBO versions |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-04-26T00:06:17Z |
Hi Jason and All,
A thread in firebird-devel this week has exposed a gotcha in very old versions of IBO that will bite you if you try to use these old apps with the F 2.0.x and Fb 2.1 client libraries:
Line 17054 of components.pas:
with IB_Session do
begin
asm fstcw [SaveCW] end;
errcode := isc_dsql_allocate_statement(
// errcode := isc_dsql_alloc_statement2(
@status,
PdbHandle,
PstHandle );
The commented-out line was the active code in the version of IBO that the OP was using (IBO 3.6 Dg from around the turn of the year 2001/2002). Jason seems to have switched the active code line back and forth for several releases after that, until v.4.2F in October 2001, when it seems to have settled into using isc_dsql_allocate_statement(). (For the old versions you'll need to dig around in IBA_Connection.IMP.) I don't have all of the subrelease sources from then until now, so I can't say for certain that isc_dsql_allocate_statement2() has not resurfaced in IBO since that time.
The problem that the affected versions of IBO have with isc_dsql_allocate_statement2() has arisen due to the optimizations that Vlad has done to the remote interface for the Fb 2 series. It appears that the new API code for isc_dsql_allocate_statement2() now depends on the original statement handle remaining available for the life of the statement, in order for the statement to be correctly deallocated during the connection closeout.
As far as I can tell, IBO dereferences the original statement handles after storing them (I can't figure out this code...) IBO (properly) takes care of deallocating and cleaning up all still-allocated statements during SysDisconnect and in IB_Connection's destructor, but unfortunately, with the Fb 2 client, the API's attempt to reference the dereferenced original statement handles results in an AV that crashes fbclient.dll.
For backward compatibility, Vlad has rolled back this undocumented change and has sent a new version of Fbclient.dll to the OP, who confirms that it has solved his problem. For now, I'll try to get a copy of this revised client from Vlad and put it into the Files area of the list for users of these very old IBO versions to try out if they encounter this problem. Sorry, I can't seem to find a tracker number for this fix at the moment.
It seems that some other data access interfaces, including recent versions, are suffering with the same problem, which seems especially evident with reference to Fbembed.dll. I don't know yet whether an Fbembed.dll with this change is available right now, but I'll ask about it.
Be aware that we're looking here at a fix for one bit of broken code in the interface, not a magic bullet that will make pre-IBO 4.8 code work out-of-the-box with Fb 2...
Helen
A thread in firebird-devel this week has exposed a gotcha in very old versions of IBO that will bite you if you try to use these old apps with the F 2.0.x and Fb 2.1 client libraries:
Line 17054 of components.pas:
with IB_Session do
begin
asm fstcw [SaveCW] end;
errcode := isc_dsql_allocate_statement(
// errcode := isc_dsql_alloc_statement2(
@status,
PdbHandle,
PstHandle );
The commented-out line was the active code in the version of IBO that the OP was using (IBO 3.6 Dg from around the turn of the year 2001/2002). Jason seems to have switched the active code line back and forth for several releases after that, until v.4.2F in October 2001, when it seems to have settled into using isc_dsql_allocate_statement(). (For the old versions you'll need to dig around in IBA_Connection.IMP.) I don't have all of the subrelease sources from then until now, so I can't say for certain that isc_dsql_allocate_statement2() has not resurfaced in IBO since that time.
The problem that the affected versions of IBO have with isc_dsql_allocate_statement2() has arisen due to the optimizations that Vlad has done to the remote interface for the Fb 2 series. It appears that the new API code for isc_dsql_allocate_statement2() now depends on the original statement handle remaining available for the life of the statement, in order for the statement to be correctly deallocated during the connection closeout.
As far as I can tell, IBO dereferences the original statement handles after storing them (I can't figure out this code...) IBO (properly) takes care of deallocating and cleaning up all still-allocated statements during SysDisconnect and in IB_Connection's destructor, but unfortunately, with the Fb 2 client, the API's attempt to reference the dereferenced original statement handles results in an AV that crashes fbclient.dll.
For backward compatibility, Vlad has rolled back this undocumented change and has sent a new version of Fbclient.dll to the OP, who confirms that it has solved his problem. For now, I'll try to get a copy of this revised client from Vlad and put it into the Files area of the list for users of these very old IBO versions to try out if they encounter this problem. Sorry, I can't seem to find a tracker number for this fix at the moment.
It seems that some other data access interfaces, including recent versions, are suffering with the same problem, which seems especially evident with reference to Fbembed.dll. I don't know yet whether an Fbembed.dll with this change is available right now, but I'll ask about it.
Be aware that we're looking here at a fix for one bit of broken code in the interface, not a magic bullet that will make pre-IBO 4.8 code work out-of-the-box with Fb 2...
Helen