Thanks for your awesome reply Helen.

A reboot of there server removed the problem so I assume it was some other application accessing the DB, possibly a backup system as you mentioned.

Your comments about the temp directory are interesting. As we don't 'do' the database installation ourselves, users use the windows installer from our CD, we might have to look at modifying the .conf file ourselves. One of the best features of FB is the easy installation and maintenance.

Once again thanks for the time and effort you put in to your response.

Merry xmas

Rob Martin
Software Engineer

phone +64 03 377 0495
fax +64 03 377 0496
web www.chreos.com
Wild Software Ltd

----- Original Message -----
From: Helen Borrie
To: firebird-support@yahoogroups.com
Sent: Tuesday, December 21, 2004 12:01 PM
Subject: Re: [firebird-support] Help - ISC error 335544373


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




[Non-text portions of this message have been removed]