At 02:22 PM 10/05/2003 +0100, Artur Anjos wrote:

>Fabiano,
>
> > > -Connecting to DB during restore
>Probably the server must refuse connections when a restore is taken place.

Unfortunately, it doesn't refuse connections while a restore is taking
place. I agree, it would be nice if it did. However, the first thing
Restore does is to create the file for the database and then use some of
the stored meta-metadata to create the database itself. Once the file
exists and the database exists, users can log into it, even though the
restore process is still continuing.

>Just do a restore using another name for the database, and after is finished
>rename it.

If you have no way to control which users may log in and when they may do
so, then this is the best advice. If at all possible, you should avoid
using the capability to overwrite a live database. Only SYSDBA and the
database owner are authorised to use gback -r ---but I've seen some really
scary setups for automated backup/restores. Be careful about who gets
SYSDBA or owner access out there.

> > -Copying the database file(s) while in use
>I don't know any way to prevent this to happen in the engine.

No, the engine has no control over what happens outside in the filesystem
environment.

>Note that the original Database is not corrupted, just the copy that was
>made using this process.

Unfortunately, not true. File-copying and compression utilities lock
sectors of the disk while they perform their work. This can have
devastating effects on uncommitted work, mess up synchronisation, cause
pieces of the jigsaw puzzle to get lost, etc. Teach your system admins to
understand what goes on in the filesystem when they kick off Winzip or
their backup program.

> > > -Deleting the current row in an UPDATE trigger
>Ops. Never tried this. Can someone confirm this?

Erk. It would be fun to experiment.

> > > -Too many transactions
>Can anyone confirm if this could lead to corruption?

Weird. How many is too many?

> > I thought mixing local and remote connections on the same
>database, but
> > maybe can someone confirm that.
>This should not create corruption. The engine is responsible for this.

Not that I know of. IB has always been able to accept a mix of local and
remote connections. The command-line tools all connect locally in normal use.

But we've heard of a lot of cases where the connection string bug causes
deadly corruption in cases where remote uses are logged in using one
connection format and someone at the server uses a command-line tool or an
Admin tool to change data, using the other format.

But, as Artur indicated, Firebird was fixed long ago to prevent the
condition occurring. IB databases continue to be vulnerable.

heLen