On May 10, 2003 09:22 am, Artur Anjos wrote:

> Fabiano,
>
> Take a look at the problems one-by-one:
> > > -Changing metadata while database in use
>
> This one should send a error message, but should not cause corruption.
> If it does (I never had a corruption problem caused by this) it's
> really something that should be fixed.

Agreed.... I don't think this is a problem though, changing metadata on a
live database is a common enough procedure that if this were a problem it
would be very well known.

>
> > > -Connecting to DB during restore
>
> Probably the server must refuse connections when a restore is taken
> place. Just do a restore using another name for the database, and after
> is finished rename it.

I can think of a simple fix for this one, add a restore_mode flag to the
database, whenever someone tries to connect, the engine checks the flag,
if the flag is set, then the connection is NOT allowed. As early as
possible in the restore process, it sets the flag. The last thing
restore does is unset this flag.

>
> > > -Connection strings mismatched
>
> Not a problem in Firebird 1. Already fixed.
>
> > > -Copying the database file(s) while in use
>
> I don't know any way to prevent this to happen in the engine. Note that
> the original Database is not corrupted, just the copy that was made
> using this process.

The original can sometimes be corrupted, if the copy program has locked
sectors of the disk, or parts of a file. The engine might not be able to
do anything about it, but perhaps it could detect that another process
has locked sectors or part of the file, and simply wait for the other
process to unlock and then continue.

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

I have not tried it either, but if it is a problem, it should be
detectable, and throw an error event.

> > > -Mismatched client and server versions
>
> No way to correct this at engine level.

Maybe, the client could identify its version number to the engine, and
the engine could then refuse to allow a connection to an old client. For
example if the engine is version 2.0 and the client is 1.5 then it could
refuse the connection. However if the engine is 2.0.7.13 and the client
is 2.0.2.53 then it would allow the connection, but give a warning.

>
> > > -Server crashes
>
> No way to correct this at engine level. :-)
>
> > > -Too many transactions
>
> Can anyone confirm if this could lead to corruption?
>

If so how many is too many, and can we set a limit slightly below this....