Helen, Adam,

> So, if Luc is seeing >>something<< barging in and locking the
> database file while the Superserver already has the write lock, he's
> seeing something pretty ruthless at work, quite possibly some
> third-party app like Nessus. One does have to suspect VSC, on the
> evidence, especially if Luc can establish that the problem *always*
> occurs at or near a point where the volume shadowing service is
> running. I think it first has to be established whether any client
> connections are active when the problem occurs.
>
> FYI, the reason for the exclusive write lock is that it prevents the
> "path bug" that corrupts databases on Windows under SS in
> InterBase. So - I wonder if Luc has checked whether the user
> encountering the problem, i.e. the user who is causing the log entry
> to be written, is attempting to connect with a "bad" path. If the
> naughty user was first to connect, using some tool he downloaded from
> the web, and used "c:data\mydb.fdb", then everyone using Luc's
> application (with the >>good<< path string, "c:\data\mydb.fdb") will
> get blocked out.

No.
The error occurs even if noone tries to connect to the database.

The program is started with a batch file (including all the start
parameters so that it's running without any active window; i.e. it might
be started as a scheduled task). Then it starts importing data and then
accessing these records (fetching from a cursor), doing some long
operations on every record, writing back some values to the database.

You can connect to the database by starting the applciation in visible
mode, no problem.
There's no problem either in having multiple instances of the app
connecting to the database, nor connecting from different machines
simultaneously.

Usually the long running batch is the program that's started first, so
this connection is initializing the "file lock".
If there'd be a bad connection string then I'd expect that program
that's issuing it having to handle the error, and not mine ;-)

The only other process that might connect is a batch file that's
starting the database backup (gbak), but that isn't the problem either.

So I'm just waiting for the system log to see if the
VSC did start again, even though we disabled the service.

By the way: All the HD volumes of this machine were excluded from the
VSC in advance.

If the problem continues: Should I give 1.5.3.CS a chance?

Luc.