--- In firebird-support@yahoogroups.com, Thekla Damaschke
<thekla.damaschke@...> wrote:

>
> Hello,
> I need some advice about which firebird to use and how to set it up.
> The following is what I want to achieve:
> There is a couple of main databases that are accessed the "normal"

way on a

> database server (oracle), but then we have "scenarios" of this,

which are

> copies or extracts of a main database used for heavy evaluations.
> To do a scenario does involve creating several copies or extracts of a
> main database,
> and for each of them start an evaluation job on some machine in the
> network. An evaluation job will
> consist of several processes that interact and work against the same
> database
> (all of them running on a single machine).
> After a while, some of the evaluations will have achieved
> some results and write a report to file/web which a human user will
> compare and decide
> which of the results he wants to put into the main database (if any).
> All the scenario databases are thrown away after this.
>
> We had first an implementation using oracle, but this was not scalable
> enough,
> oracle has obviously problems when you create and drop users amass all
> the time :-)
> I thought that firebird might be a good solution, since each scenario
> would just be a file,
> we could distribute them on the net and then run each evaluation in
> complete isolation.
> I really like that firebird support so broad SQL syntax compared to

other

> filebased or embedded databases that I looked at.
>
> I have implemented the access layer against firebird (using embedded as
> starting point)
> and it was really smooth. Great !
> But now, to set it live, I need some help on the alternatives:
>
> If I got it right, superserver needs something running continuously
> on each machine I want a distributed database to end up on,
> while classic server should be integrated with inetd and will start up
> on request
> (one process per database connection).
> Both of them should cope with new databases turning up on the fly
> and shouldn't care if a database vanishes once it is not longer
> accessed, right ?

Correct.

>
> What is this about local connections,

The thread you replied to was specific to Windows. I do not know how
it relates to Linux.

A local connection string looks like

'c:\data\mydb.fdb'

or

'/data/mydb.fdb'

> what is the actual difference to connections to localhost?

A TCP connection has the hostname or IP in front.

'server:c:\data\mydb.fdb'

or

'server:/data/mydb.fdb'

In Windows, you need to use a TCP connection string to connect to a
classic server of to connect to a Superserver through terminal services.

I don't think this is an issue on Linux but someone else can clarify.

> In which environment are they supported and what need to be running
> already on the box?
> I got a bit confused by the different statements in the documentation.
> From the Whitepaper that is linked from firebird website, I get:
> "*Local Access Method *
> The Classic architecture permits application processes to perform

I/O on

> database files directly, whereas the SuperServer architecture requires
> applications to request the *ibserver* I/O operations by proxy, using a
> network method. The local access method is faster than the network
> access method, but is only usable by applications which run on the same
> host as the database."
>
> while in the support mailinglist, Adam writes:
>
> >* Classic Server
> >
> >There is no local connection support. Use TCP loopback to localhost to
> >resolve.

You are taking both the documentation and me out of context. The
documentation is referring to linux. My comments were referring to
Windows. Local connection is faster, but is not available to Classic
running on Windows servers.

> What architecture requires least effort and rights to set it up on a

new

> box ?
> Optimally I would like to have an NFS mounted (or tarball) installation
> of firebird
> and no local preparation. I could run some script to set up something
> for each
> scenario (or the first one) that I copy on the box, but that should not
> require root access!

Linux install is a little more involved than Windows, but read the
quick start guide then post more specific questions if you have trouble.

Adam