Subject RE: [ib-support] What's this mean
Author Wilson, Fred
The "owner of the database" is the user that I tried connecting with, and is
the one that the user applications would connect with. We (currently) use
the same user (NOT sysdba) for all the applications in the field and also
the scripts that handle the backup and restore. So, to re-cap. I can, drop
the database, start a restore (using a user other than sysdba) and then,
from another client, log into the database while the restore is running with
the user name that's doing the restore (not sysdba).

Fred Wilson
SE, Bell & Howell

-----Original Message-----
From: Jason Chapman (JAC2) [mailto:jason@...]
Sent: Sunday, March 31, 2002 8:53 AM
Subject: Re: [ib-support] What's this mean

> Mmmmmm, well, that does *not* appear to be the case (IB5.6).. I just
> d
> a restore (after dropping a database), and was able, with no problems, to
> log into the database (via WISQL) and do a select * from xxxx...
> (While Ann thinks...)
> I don't think this is possible. Gbak creates the restore db in a shutdown
> state and without forced writes. It does all the data restore, then before
> detaching from the newly created db, it sets the db to multi-user mode
> n
> and sets forced writes. If you try to connect in the meantime, you will
> :
> Of course, if sysdba tries to connect, it will succeed. Maybe even sysdba
> should be forbidden if the previous (and hopefully only) attachment is
> g
> held by gbak, since it doesn't make sense to interfere at this time.
> Whatever happens, once gbak exists for good or bad reason, sysdba would be
> able to connect anyway, so why allowing it to log in a db being restored?
And certainly the owned of the database as well.

To unsubscribe from this group, send an email to:

Your use of Yahoo! Groups is subject to