At 12:59 PM 3/09/2003 +0200, you wrote:

> > With a client/server install, you have one main server that runs the
> > Firebird
> > server process - clients connect to a database via the server process.
> >
>
>... perfect, this is how I have understood the whole thing!
>
>
> > As you have found out, Firebird cannot use the UNC path, because it
> > isn't a true local to a database file.
>
>... unfortunately, this is true!

Then, Thomas, you have not understood the whole thing at all!!

Applications like word processors and spreadshets use UNC paths to find
files. That's because those applications work on files. Clients of
client/server databases do not. Clients never touch database files.

When we talk about a "database server" we mean software that serves client
requests. (This software also happens to provide management services to
the data that are stored in it...) The physical machine that this software
runs on is also called a "server" because it provides facilities to server
applications. One of these facilities that the db server needs is for the
physical storage space that it manages to be under the physical control of
the server machine.

Another common name for the server machine is the host. Now, each of the
servers in your network has a host name that is hard coded, along with
other attributes such as its IP address. That is the host name that
database clients need to know. It is not, and cannot be, a mapped drive or
a share. It is not necessary to share the host that is running your
database server. In fact, it is not even advisable to do so.

Let's say that the host which is running your db server is named
"DBSERVER". When the Firebird server is running, the host DBSERVER is the
**host server** of one or many Firebird databases being managed on
DBSERVER's physical filesystem.

Now, moving over to a client. A client consists of an application program
and an interface to the server. Unless you are running a Java client, the
Windows program that each client workstation has to have in its %SYSTEM%
directory is called gds32.dll in Firebird 1.0.x and fbclient.dll in
Firebird 1.5. This library exposes a large number of functional structures
to client applications to accept requests for hundreds of database operations.

The first database operation that a client application has to do is a
connection request to (usually) one database. The application sends this
connection request to the client dll. The client dll has its own network
channel for negotiating with the database. This channel exists "above" the
physical network layer, not within it. This client/server channel is the
same, whether the client is talking to the server in a LAN using NetBEUI or
TCP/IP, or from outside the LAN, via SSL or TCP/IP on the satellite
network, or whatever.

You *happen* to have Windows clients, but this need not be the case. Your
server could be connected to by clients on Linux machines or Apple
workstations. All the client applications need in order to have the server
find the correct database are
the HOST NAME
the PHYSICAL LOCATION of the database file on that host and
an open physical network channel (NetBEUI or TCP/IP).

So you see, there is no place in that physical model to be passing virtual
device addresses. It can't even be permitted to quiz a virtual device
address in order to find the physical location, since there is nothing to
prevent an invalid file path being determined.

The choice of whether the channel between the client dll and the server
uses NetBEUI or TCP/IP is made by the client application. Using our host
name DBSERVER, requesting a connection to database whose file path is
d:\data\TheDatabase, a client will request a NetBEUI pipe using this syntax
for the connection string:
\\DBSERVER\d:\data\TheDatabase

Or it will request a TCP/IP connection using this string:
DBSERVER:d:\data\TheDatabase

As others have explained, if you want users to be able to select the
database they connect to, then all that's needed is to store the valid
paths in an INI file (or other text file) on the client
workstation. Alternatively, you can store them in a Registry key. They
are only strings.

Firebird 1.5 has a better solution. It lets you store aliases for all of
the database paths on your server, in a server-based text file named
aliases.conf. So, you can store, e.g.

DB1=d:\data\TheDatabase

Then your client connection string is much easier:
For NetBEUI: \\DBSERVER\:DB1
For TCP/IP: DBSERVER:DB1

The main aim of this is wire security - a sniffer cannot determined the
physical location of the database file from an alias.
The other big advantage is that you can "soft-code" the database file path
into your applications, regardless of where they will be deployed. Each
host server will have its own local set of aliases point to the actual
filenames.

Martijn wrote:

> > I wonder why you need a local database in the first place - can you
>explain
> > a bit more? Personally, I would use a remote database only, unless the
> > situation tells me differently.
>
>... on a client I perform fast instrument read/write access operations and
>read large amounts of data that I have to buffer before saving an extract of
>that data into the global database. I do this by buffering the data into the
>local database to make sure that I do not slow down other client processes
>that try to access the global database server on a routinely basis.

This is probably valid, if you need to buffer your input streams and
massage them for timed batches, and other processes in the system are not
waiting for those data. For an OLTP system it sounds quite awful. From a
network load management POV it sounds awful, unless you are going to do
those feeds at off-peak times.

>Furthermore, the local database is used to store the location to the global
>database and setup information for the client application.

This is NOT a sensible idea at all. Your client applications only need a
string.

The VERY WORST thing you can do is to allow end-users to go searching
around the network to locate the database file - a file that their
application code never touches.

heLen