--- In firebird-support@yahoogroups.com, "Adam" <s3057043@y...>
wrote:

>
> --- In firebird-support@yahoogroups.com, "Tony Masefield"
> <polsolsa@y...> wrote:
> >
> > Hi All,
> >
> > 1) What are the minimum files that need to be installed on a
> > Firebird client and server (assuming that no third party UDF's

etc

> > are necessary)? The Firebird 'EXE' installer works great but at
> some
> > time I will need to write my own installation package for both
> > server and client (to minimise complications).
> >
>
> I have never bothered to check which ones the server needs, our
> installer simply executes the Firebird installer, but I am sure it

is

> documented somewhere what the installer puts where. There is a zip
> file version of the windows install which might help you out too.
>

What I'm trying to avoid is to place all the tools, and any other
extraneous files on the server and "stop people fiddling" with the
server/DB. OK, so some tools may be necesary for the DB
administrator but I worry (because I have met) some administrators
who are not too au fey with DB Administration (I know pretty much
diddly squat but have met some who know less than I). Some of the
companies I know place DB administration under the finance personnel
rather than employee proffesionals ....)
I think that the ZIP file, from memory, contains the whole caboudle.

> > 3) Assuming that the applications use aliases (simpler for
> > installation), then Aliases.Conf must be on the client rather

than

> > server or both (seems self evident but ....)?
>
> Nope, on the server only. The only thing you need on the client is
> fbclient.dll or gds32.dll and which one depends on what components
> you are using. Aliases are good for hiding the physical location

of

> the database file from the clients.
>

Yes, but 'thinking out loud' maybe I should consider writing an
encoded 'INI' type file for each customer (once I get the server and
DB details from the customer) and read (+ decode) from the
application itself (see comments below). This would negate the
requirement for aliase.conf and add a level of security [i.e. no one
could copy (at least that easily) the application itself and use on
another system]?

> >
> > 4) Do the 'standard' components (like IBO 4.5) work with aliases?
> >
>
> All the ones I have used do. This doesn't include IBO but I would

be

> incredible surprised if they didn't.
>
> DatabaseName property (or equivalent) should be in the form
>
> host:alias
>
> So if your server is "MyServer" and there is an alias

called "MyDB"

> on that server, then a client can use the connection.
>
> MyServer:MyDB

If one has to physically encode the server name into the application
software then this seems to limit the usefulness of using aliases.
One must know the server name before hand and thus 're-write' the
software and compile for each individual customer (actually I'm
talking about software that would be common to a whole host of
customers rather than writing different software for different
customers - should have specified this at the outset).
The client would have to know the server name to connect - which is
why I had assumed that alias.conf (repleat with server name) should
be on the client and the designated component (such as IBODatabase -
BTW just checked this component and it does have an Alias property)
would extract this info from the alias before trying to connect.
Then again as a Newbie I could be wrong ...!
The alternative, I suppose, would be to add the server name as a
command line argument for the application itself.

Thanks for the help Adam.