> 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).

No it runs no script and yes the connection pool is active, since the
database exists, but not the structure.

> 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.

I'm using autocommit in Java for issuing all this anyway, so everything
is always committed. Anyway, Firebird doesn't seem to isolate metadata
changes in transactions. They seem to 'bleed through'.

> 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?

The database does exist, the structure is created automatically.

> 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.

I searched the mailinglists and could only find a few, without any real
discussion. Just 'you should to this with only one connection active or
reset all your connections'.

http://www.google.com/search?q=site%3Awww.ibphoenix.com+foreign+key

I'm very interested to know where you found million and one
discussions, and if they are there maybe they indicate a real demand.

--
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34
http://www.uwyn.com 7170 Manage
gbevin[remove] at uwyn dot com Tel +32 64 84 80 03

PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net