Subject Re: [firebird-support] Foreign keys
Author Geert Bevin
Btw, there's one use case you seem to be forgetting. What about a real
production database where other web applications are already running
from it? Some ISP only allow one database instance, or a limited amount
of them. So you suggest that to install a new application, one should
shut down all the others, create the new structure manually and them
put everything up again. Surely you can't be serious about this in a
production environment?

On 17 Jul 2004, at 09:50, Alan McDonald wrote:

>> 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 website knowledge base for all
> the
> information you need on this subject.
> Alan
> Yahoo! Groups Links
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34 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,