Hi Helen,

.. thanks a lof for your detailed and clear descritpion. I start to
understand things!

Thanks,
/Thomas

> > > 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 synta

x

> 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
>
>
>
>
> To unsubscribe from this group, send an email to:
> firebird-support-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>