We have a similar setup here. We are running Firebird 1 on a Windows
2000 server box. Client connections to the database are via TCP/IP
and the server is also connected to our Novell Network.

Daily backups under this arrangement are almost trivial. The server
has a batch file, running under the control of the Window scheduler
(that triggers twice a day at preset times), that invokes a batch
file stored on the Network which calls gbak with suitable
parameters. GBAK places the backup file onto the Network via a
mapped drive and it is then picked up by the network backup
procedures.

This arrangement ensures that we have regular backups that are taken
without any interruption of service

--- In ib-support@y..., Doug Chamberlin <DChamberlin@A...> wrote:
> At 07/10/2002 07:31 PM (Wednesday), Paul M. wrote:
> >He was mapping the server's drive, then setting
z:\thepath\theDBfile.gdb as
> >the database to connect to, assuming that z: is the mapped drive.
The DB
> >Server is running on the NTServer whose drive is being mapped.
>
> Mapping the drive is a strange thing to do as it is entirely
unnecessary.
> The connection string used by the client to connect an Interbase
database
> should include the address of the database and then a path to the
GDB file.
> The path should always be from the viewpoint of the Interbase
server
> machine. This is true regardless of the communications protocol
used
> between the client and server.
>
> >I recommended that he switched to TCP/IP to access the DB, which
he did.
> >However, after a period of time, this caused the server to lock
out all the
> >clients.
>
> Simply switching to TCP/IP will not cause this lockout.
>
> >I think I've sorted out the problem now, though. He had a small
app running
> >on the server that backed up the database at half hour intervals,
which was
> >still accessing it via the path, rather than TCP/IP. Someone else
has
> >informed me that if you use two different protocols to access the
DB,
> >Interbase can crash. Therefore I'm pretty sure that this is the
problem, and
> >that the disconnected machine was a red herring.
>
> Having a small app which backs up the database file is also a
strange thing
> to do. Any access of the GDB file except by the Interbase server
process is
> a problem. The only case when this should be attempted is when the
server
> process is NOT running or when you are absolutely sure the there
are no
> current connections to that GDB file.
>
> The usual and proper way to make a backup of an Interbase is to
use
> GBAK.EXE (or equivalent) to make a backup copy and then use your
normal
> backup software to store that copy somewhere safe. Any other
access of the
> GDB file will either yield a corrupted GDB copy or lock out normal
access
> by the Interbase server (and, therefore, user access).
>
> I think you are correct in concluding that disconnecting the
client machine
> was causing a problem. It sounds just coincidental. The other
practices you
> mention, however, are serious problems.