| Subject | RE: [IBO] Client Library Issues |
|---|---|
| Author | Jason Wharton |
| Post date | 2005-04-15T15:21:59Z |
Geoff,
What I would like to see is the creation of a client dll that actually is
intelligent enough to maintain a conversation on the wire with the different
versions of firebird and InterBase. That would save everyone a huge amount
of hassle. That is what I have expected out of Borland, the original
publisher of this gds32.dll, and out of firebird who continues to value
backwards and upwards compatibility with this dll.
The only other solution I can think of that is fairly clean is to have each
database connection dynamically load a client library at the time a
connection is requested and for the connection to have a property specifying
what client library it is to use. Where this gets tricky is in the case
where two phase commit transactions that span multiple databases are
concerned.
Where this could go is to have a property on the connection which would be
compared with the client the session has and if the connection didn't
specify a different client it would just use the session-level client.
Thus, people could override a connection's client if necessary, but they
wouldn't be able to have a transaction span connections that were invoked
across two connections via two client sessions.
In short, there is no totally functional situation I can deliver in IBO. A
complete solution may only be attained via a single client library that is
written to maintain a conversation on the wire with all the different
flavors of servers out there.
Jason Wharton
What I would like to see is the creation of a client dll that actually is
intelligent enough to maintain a conversation on the wire with the different
versions of firebird and InterBase. That would save everyone a huge amount
of hassle. That is what I have expected out of Borland, the original
publisher of this gds32.dll, and out of firebird who continues to value
backwards and upwards compatibility with this dll.
The only other solution I can think of that is fairly clean is to have each
database connection dynamically load a client library at the time a
connection is requested and for the connection to have a property specifying
what client library it is to use. Where this gets tricky is in the case
where two phase commit transactions that span multiple databases are
concerned.
Where this could go is to have a property on the connection which would be
compared with the client the session has and if the connection didn't
specify a different client it would just use the session-level client.
Thus, people could override a connection's client if necessary, but they
wouldn't be able to have a transaction span connections that were invoked
across two connections via two client sessions.
In short, there is no totally functional situation I can deliver in IBO. A
complete solution may only be attained via a single client library that is
written to maintain a conversation on the wire with all the different
flavors of servers out there.
Jason Wharton
> -----Original Message-----
> From: Geoff Worboys [mailto:geoff@...]
> Sent: Thursday, April 14, 2005 1:03 AM
> To: Salvatore Besso
> Subject: Re: [IBO] Client Library Issues
>
>
>
> > and what about doing as IBExpert does? In the database
> > registration you have to specify the Firebird or Interbase
> > client path and name. You could offer this in your program's
> > options.
>
> As an extension or addition yes. Indeed IBObjects really does
> need some way for the application to specify the library name
> before it tries to load the client library - to allow for
> custom installations and possibly even custom client libraries.
> At the moment the only way to do this in IBO is to change the
> IBO source which is far from ideal.
>
> But as a default behaviour it would (IMO) be best if IBO tried
> to be a bit smarter. I would much rather not insist that every
> database has to have a library registered just because the IBO
> selection of gds32.dll is not what I want.
>
> --
> Geoff Worboys
> Telesis Computing
>
>
>