At 09:38 AM 12/1/00 -0500, Leyne, Sean wrote:

>Jason,
>
>I must disagree with you.
>
>The Interbase engine CAN NOT access non-local files, accordingly, a UNC
>path must be processed by a remote server. Since a UNC path has the
>same structure as a NETBEUI connection string, IB attempts an connection
>accordingly.
>

Actually the engine could, has, and might again access non-local files.

The problem is not the engine, per se, but a combination of two other
factors:

1. A general inability to enforce exclusive access to a non-local
file. (The first version of NFS had absolutely no file
locking.)

2. The possibility that a non-local database was created by an
engine from a non-family architecture (backward bytes,
different alignment rules, different floating point, etc).

The Apollo version was an example of non-local access. During
the attach sequence (everybody was paying attention yesterday,
right?), the engine tries to open the database file with exclusive
access. If the engine couldn't open the file, it errored. The
Apollo ring remote access, when its turn rolled around, found out
what node had the file open and established communication for
remote access. In short, a floating server.

Assuming the PIO for Win32 using native windows calls (a less lazy
person would have checked by now), it is perfectly safe to let
an engine open a database file on a disk server. Whether an
analysis of network traffic for disk access vs network traffic
for database access makes this reasonable is a different question;
in general you want the engine as close to the disk as possible.



Jim Starkey