On Fri, 2004-06-18 at 04:33, Lester Caine wrote:

> Am I the only person who is getting irritated by the criticism that
> Firebird is not very good as a single user built in database engine?
>
> I came to Interbase because I wanted I good client/server setup and my
> single user dbase (Codebase) based systems are STILL being installed and
> used without any problem.

Hey, if it ain't broke, don't fix it!

>
> While I can see the advantage of only having to support one database
> file format. Most of the people who have been asking for an embedded
> version will never use that file other than in the single user application.
>
> Do we need to spend time trying to full fill everybodies requirements
> with an engine that is simply NOT a single user engine. The next
> complaints will be that it could be speeded up if some of the facilities
> only used by multi user systems are removed.

Why not, currently no database comes close to providing both a single
and multi-user data access system, that is complete. As for removing
multi-user facilities, that's not hard, you make it a compile time
option.

We need to remember who the customer is, the customer in this case is
the developer who wants to use Firebird.

Suppose your the new head of IT for the village of Moose Nostril.
Rather then paying the massive licence and support fees for another
database, your going to make FB the standard. Up until now, the
computer network has been the 4 function calculator on the secretaries
desk. No matter what the project, your going to use Firebird, whether
it's the new tax system -- or the dog licence registry, your using the
same database system Firebird.

The dog registry runs on the computer at the pound -- it's stand alone,
because the network connection to out there has been approved, and will
be installed in March of 2006! Rather then rewrite that app in 2006 you
will simply swap out the embedded for the client, and move the database
to the server at city hall.


So how can we do this, well the answer my friend, is an old friend to
many of us, make. Actually better would be configure, the gnu software
make builder. Something like this:

./configure server-super # builds a super server
./configure server-classic # builds a classic server
./configure embedded-lib # builds embedded server/client

then run

make
make install

or


make
make package.

make package, depending on the platform would either build a self
extracting executable (windows) or a binary archive suitable for
installing, this could be for example an RPM file. There could be an
option at the configure stage to select which archive to build if more
then one is available.

Paul