> Look, this is a theoretical discussion with just one example. I'm
> actually having the same problems to merely run the unittests on a
> pooled connection. Sure I could setup something 'special' for Firebird,
> but it's just behaving very differently from all the others in that
> aspect.
>

in your wizard... your application starts, and recognises that the firebird
database does not exist so it needs to make one.
It runs a script (including definitions of foreign keys).
If you issue the COMMIT; at appropriate places in this script, you will not
get any errors raised. after all, this is exactly what gbak has to do during
a restore, it constructs the db with foreign keys then puts the data into to
it.
Also, at this point, connection pooling cannot be active since the db does
not exist. So why is connection pooling in the mix here at all?
Your problem is only evident, it would seem, not during db creation, but
under normal load and when you want to effect further metadata changes.
There has been a million and one discussions on this - save us regurgitating
it all and search the www.ibphoenix.com website knowledge base for all the
information you need on this subject.

Alan