--- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@m...>
wrote:

>
> Then what is your experience - cause it has never worked off a
> system drive - i.e on a share. perhaps a local mount is OK but

never

> on another PC across a network...
>

We had to fool firebird a little. Simply create the shadow on the
same machine in what will be the mount point for the share. Close all
connections, mount the share and copy the file onto the share. Reopen
connections and firebird is quite content. Obviously this method
suggests it is not good practice...

> what's "manual" shadow when it's not a shadow?
>

"CREATE SHADOW 1 MANUAL..." / "CREATE SHADOW 1 AUTO..."

Interbase 5, Operators Guide, pg 120...
- Auto - Database operative is uninterrupted [in the event of shadow
loss]
- Manual - Prevents the database from running unintentionally without
a shadow

The syntax seems to still hold true for FB1.

> and you may wish to do some more testing - unfortunately, sooner or
> later, you may get a corruption and shadowing will also get it.
>

Maybe we've been lucky so far, but except for IB5.0, we've not lost
any data to a corrupt database not directly associated with disk
failure from 4.2 upwards on a variety of OSs. Even an incredibly buggy
delphi1 app<->dodgy pc<->dodgy network<->NT4 we once had wasnt able to
screw the database - just the data and the users!

Im not trying to sound too cocky/over confident at this point, im
really after feedback on how reliable shadowing is and whether
shadowing across the network is likely to feed any additional risks
back to the main database. From the docs i expect a corruption to
propogate to the shadow its just that firebird tends not to suffer
from this (which is partly why we have stayed with it).

> Maybe you should look at the logging mechanisms offered by
> IBLogManager - there is soon to be roll-ahead logs as well as
> roll back.
>

That does sound like what we are wanting...

Thanks,

Ian