At 06:47 PM 19/10/2006, you wrote:

>Maybe once a month I find this message in the log file:
>
>C093 (Server) Thu Oct 19 08:15:48 2006
> Database: E:\DATABASE\CBSFUNGI.FDB
> internal gds software consistency check (invalid SEND request (167))
>
>After that all accesses to the database fail, because the database
>file 'is locked by another process'.

Two possibilities are the following:

1) A window occurs where no clients are logged in. If your database
file has the file extension ".gdb" then the next client that tries to
log in (and it could be a backup logging into a newly created
database too) encounters the 'locked file' problem because XP's
System Restore utility is busy taking an image of the
file. Superserver must have exclusive write access to the file. The
solution to this one is well known. Rename the database using a
different extension that is not a target of SR. Most people use the
convention ".fdb" but it can be whatever you like, including no
extension at all.

2) The client that is receiving the exception is trying to use a
different Windows path format to that used by an already logged-in
client. The two possibilities are:

E:\DATABASE\CBSFUNGI.FDB
and
E:DATABASE\CBSFUNGI.FDB

If a client is able to log in using the first format, then only
clients using that format will be able to log in. Others will get
the exception message. Likewise, if the first logged-in user uses
the second format. This is a deliberate mechanism of Firebird to
prevent Windows' duality about path formats from causing database corruption.

>The remedy is to stop and start the Guardian. There is no sign of
>damage to the database, backup and restore function without any problems.

That stopping and restarting the Guardian seems to be a remedy is
apparently coincidental. The Guardian doesn't have anything to do
with whether database files can be opened or not. It monitors
fbserver.exe to try to keep it running. If SysRestore (or some other
filesystem operation happening on your server) is preventing logins
to the database, it's possible that the time lapse between stopping
and restarting the Guardian has allowed the competing process to finish.

>The problem always occurs when the server is very busy, but not
>necessarily with the databse file that cannot be accessed afterwards.

Can't make sense of this statement, sorry.

>This morning it happened during a restore of the database to a new
>file,

Gbak creates the database file and, as soon as it tries to log on to
it, System Restore hops in, opens the file, and takes a snapshot of it.

>sometimes it happens at night during backup and compress jobs,
>when people are accessing the db over the internet.

"Compress jobs"?

And are people accessing the db over the internet through browser
clients to a server-based web application? or as 2-tier clients?

>The server is an XP server running (still) Fb 1.5.2

XP may be significant; as for 1.5.2, why don't you download the
1.5.3 release notes and study the bug fix list, to see whether
there's anything there that resonates with the problems you are seeing?

./heLen