2009/3/2 Olivier Mascia <om@...>:
> Hello Daniel,
> Le 02-mars-09 à 10:41, Daniel Albuschat a écrit :
>> I'd like to incrementally replace an existing Interbase toolkit
>> (IBObjects) with IBPP. Because I don't want to start a new
>> database-connection and -transaction, I'd like to construct a
>> IBPP::Database object from an gds-handle.
>> The current API does not provide a way to do this. Is it much work to
>> create a DatabaseFactory-function that takes a gds-handle?
>>> From what I've seen in the code it should be sufficient, in
>> DatabaseImpl, to initialize the mHandle member and read the database
>> dialect to set mDialect. Will everything else work with a shared
>> database handle? The toolkit I am replacing supports this explicitly,
>> so this should not be an issue.
> You would like to open a database connection with one toolkit, build
> an ibpp connection from that handle, and then what? Issue some
> statements from some parts of the application with one toolkit and
> others with the second one (ibpp)? And even do this for a same
> transaction? Connecting with toolset A, starting the transaction with
> toolset B, then hand this to ibpp and run some statements with ibpp?
> Who will commit?
I only care for the database connection. Of course, each toolkit will
create it's own transactions.
Actually I even succeeded, but the other way around. I just added one
line to the IDatabase interface:
virtual void *GetHandle() = 0;
Since DatabaseImpl has a function GetHandle() that returns the
interbase-handle (which is just a void*), this function is now virtual
and will be used when IDatabase::GetHandle is called. I then set
IBObject's IB_Connection.dbHandleShared property to this value and
begin to start transactions and execute statements. With my trivial
tests, it succeeded so far. Is there any potential risk in doing this?
> I really wonder why not opening a secondary connection though, but it
> should and could fly I think.
Because I want my application to have exactly one connection to the
database. This keeps some maintenance and debugging work a bit lower
and is simply "cleaner". Well, I can't really adhere to my own
guideline here, since I'm using multiple threads, though. ;-(
All in all, I may need to ditch this idea again, especially because of
the threads. But it'd be good to know whether it is possible or not.
> Note that some restrictions may apply. The client lib DLL is
> dynamically loaded by IBPP (on Windows for these versions, on unixes
> too Real Soon(TM)). It might very well not load the same one than
> other toolkit uses. Rendering the handle invalid.
Ah, thanks for the pointer. This is a potential headache, indeed.
eat(this); // delicious suicide