At 02:27 PM 14/10/2003 -0400, you wrote:

> >
> > Firebird and Interbase never could and can access a database that's on a
> > network drive (as seen from the machine were the server is running).
> > So does the embedded server.
> >
>Incorrect.

Actually, it's still correct.

>Quoting the firebird.conf from the embedded server zip file:
># ----------------------------
># Allow opening of data files on NFS volumes
>#
># Allows for database files which exists on a NFS mounted partition to
># be opened by the engine.
>#
># The original behavour was to try and connect to server on the remote
># machine via port 3050, this ensures that all opens of a file occur on
># the same machine and locking etc can be handled appropriately. However,
># this often causes frustration since often you end up in a position
># where you really do want db files to be opened by the local process
># even though it resides on a NFS share. So this option allows for this
># 'feature' to be turned off.
>#
># Type: boolean
>#
>#RemoteFileOpenAbility = 0

This is available only on *nixnux and it is HIGHLY not recommended for
anything but a read-only database.

>You're confusing a "true local server" with a "local database file". The
>ideal situation is to keep them one and the same, but it's technically
>possible to change the behavior. True local access in this case just
>refers to how the gds.dll connects to the server component.

"True local access" Windows-style: exactly and ONLY a client on the local
machine. It will NOT work with a share or a mapped drive. Even for those
who *think* they are connecting to a share or a mapped drive, it can't
work. "Windows true local" works by emulating a network connection in
shared memory space.

heLen