--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:

>
> 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.
>

The extension is .fdb

> 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.

>

I always use the first format, at least I think so, and I checked again.

> >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.
>

Stopping and restarting the Guardian also stops FBServer. After that
the database can be used again.

> >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
>

Clients are accessing the db either through a Delphi application
(FIBPlus), or through the web server which calls a Delphi ISAPI dll
which accesses the db. Both ways fail because the database file is locked.
This morning I did a restore through IBExpert of an fbk-file to an
fdb-file with a temporary name, to rename the file after the restore
succeeded. In the mean time, this invalid send request occurred on the
real database (which was not touched by the restore), and that file
was locked. The same thing occurred a number of times during the
night, when backups are made through scheduled batch jobs using gbak,
and the fbk-files are compressed (zipped) afterwards, and copied to
another server. In one case, a small database got the invalid send
request while a backup was made of another, large database. The fact
that the problem always occurs when a processor-intensive jobs is
running, and the database for which the problem occcurs is not always
involved in this job, made me think that the reason maybe was that a
request is not properly processed when the server is very busy
processing another request that takes a relatively long time.

> 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?
>

I did, I saw no reason to upgrade

> ./heLen
>

Thanks for your comments ,
Gerrit