At 10:19 AM 21/12/2004 +1300, you wrote:

>Hi All
>
>One of our users reports the following error message whenever they start our
>application.
>
>ISC error 335544373
>
>Operating system directive create file failed

The above is a Firebird engine exception: the engine tried to create or
open a file and the operating system refused the request.

>The requested operation cannot be performed on a file with a user-mapped
>section open.

This one comes from the operating system.

>Any ideas what is causing this?

It could be that the database the application is connecting to (or possibly
even the security database) is on a mapped drive. i.e. the host server is
not a physical node on the network.

It could be that the application starts up by opening an ordered or grouped
dataset. If the server isn't Fb 1.5 then the server needs temporary space
on disk for sorting. But probably even Fb 1.5 needs to know that it has
access to the sort space, even if there's plenty of RAM and it never needs
to use the disk for sorts. If you have not configured this space
explicitly, and the host's \tmp or \temp directory is pointing to a mapped
location, then Firebird won't be able to access it. Fix this by explicitly
configuring sort space on the host's own drives - something you should do
anyway, given the arbitrary way Windows manages temporary space.

If you can eliminate these possibilities, then check whether they are using
a filesystem backup utility that uses mappings to access directories on the
network. These filesystem utilities lock sectors of disk. The Superserver
can't access a database (security.fdb or a user database) if it can't get
an exclusive lock on the file.

If it's Server2003, make sure that the Disk Shadowing "feature" is set to
exclude the Firebird root directory and locations where their Firebird
databases are.

If filesystem utilities are allowed to run when users might be connected to
databases, they must be configured to exclude any directories containing
Firebird databases - including the Firebird root directory, of
course. .Note that Firebird database backups must be done with gbak.

Could it be that an ad hoc user is using some external query tool such as
Access to open the database through an ODBC DSN that maps to logical
server? AFAIU, this shouldn't be possible but there's a first time for
everything.

What network protocol is your application using to access the database?

>The user is currently restarting there server to see if that will rectify
>the issue. The machine runs windows 2000 Server with 2 Xenon CPUs / Raid
>and a bucket load or ram.

This is a filesystem conflict of some kind...

./hb