Pete,

Firebird is a bit of a mind shift from the world you are used to
working with (as you've already discovered).

In the dBase/Paradox/Access world the applications access datafiles
directly. In essense, you have multiple database servers accessing
common datafiles. This is precisely the reason these solutions do
not scale well.

In the client/server database world where Firebird lives, you have
one database server access the datafiles that the clients can
not/should not see. The server (in this case Firebird) handles
access to the files and the acts as a traffic cop/request broker from
the clients. The clients connect to the server software, not the
data files on the server. In practice what this means is that you
install the Firebird server (Classic or Super) only on the server --
never on the clients. Only the Firebird client software is installed
on the clients. This is the same process/implementation you will
find with Oracle, Sybase, MS SQL Server, MySQL, or any other
client/server database system.

For example, say you have 3 computers: FBServer, client1, and client2.

On FBServer you would install the Firebird server -- again either
Classic or Super (Super is recommended).

On client1 and client2 you would install just the Firebird Client
software and whatever your applications are.

One thing I haven't seen mentioned in this thread that may make it
easier for you is the concept of aliases. An alias is a 'simple'
name for a database location on the server. For example, say you
have an employee database that is physically located at
d:\datafiles\employee.fdb on the server. To set up an alias, look
for the file aliases.conf on the server (no need to worry about the
clients). Add the following line to the end of the file:

employee d:\datafiles\employee.fdb

Now, rather than making each client connection "know" the location of
the datafile via the connection
string "FBServer:d:\datafiles\employee.fdb" you could reference
the "employee" alias. Now your connection string from the client
would look like "FBServer:employee".

The key point to remember is that the clients talk to the Firebird
server and do not access the datafiles directly. In fact, while it
is technically possible to have multiple server access a common
datafile doing so causes all sorts of data corruption problems.
Definitely not recommended.

Another important point -- the Firebird datafile must be on a drive
physically connected to the server -- not a network share.

-Cory

--- In firebird-support@yahoogroups.com, "petesouthwest"
<petesouthwest@h...> wrote:

> Further to this:
>
> If Firebird is being installed directly to the server, will the

drive

> letter selected as the destination appear the same letter to the
> network? ie if the client machines see a drive 'T' that is a

harddisk

> on server 3, when Firebird installs to server 3, will it be

installed

> to T:\program files\firebird etc or will it be c:\....?
>
> Thanks
> Pete
>
> --- In firebird-support@yahoogroups.com, "petesouthwest"
> <petesouthwest@h...> wrote:
> > Hi
> >
> > I'm trying to get clear in my mind how I can get my app to

connect

> to its database, with the minimal hassle to the person installing

it.

> >
> > On that basis I have been trying to work out how to convert a UNC
> path into the hostName:drive: protocol needed. However, It has
> occurred to me that as the firebird installation interrogates and
> makes changes to the server (registry presumably), so it runs
> automatically as either a service or an application, surely the set-
> up exe needs to execute on the server rather than on a pc connected
> to the server?
> >
> > Sorry for what is probably another stupid question!
> >
> > Thanks
> > Pete
> >
> > [Non-text portions of this message have been removed]