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

Best,
Fred Wilson
SE, Bell & Howell
fred.wilson@...



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

> Mmmmmm, well, that does *not* appear to be the case (IB5.6).. I just

starte=

> 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

agai=

> n
> and sets forced writes. If you try to connect in the meantime, you will

get=

> :
> Of course, if sysdba tries to connect, it will succeed. Maybe even sysdba
> should be forbidden if the previous (and hopefully only) attachment is

bein=

> 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:
ib-support-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/