| Subject | RE: [ib-support] Interbase disconnecting all clients |
|---|---|
| Author | Doug Chamberlin |
| Post date | 2002-07-11T01:20:19Z |
At 07/10/2002 07:31 PM (Wednesday), Paul M. wrote:
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.
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.
>He was mapping the server's drive, then setting z:\thepath\theDBfile.gdb asMapping the drive is a strange thing to do as it is entirely unnecessary.
>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.
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.Simply switching to TCP/IP will not cause this lockout.
>However, after a period of time, this caused the server to lock out all the
>clients.
>I think I've sorted out the problem now, though. He had a small app runningHaving a small app which backs up the database file is also a strange thing
>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.
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.