Fabricio Araujo wrote:

> Not when the system is already composed of 6 different
> applications - this including the simulation engine, the
> visual interface app, the data management app, the
> command dispatcher, and conflict calculation app.
>
> All of then communicating almost only by the DB.
>
> A 3-tier would make the persistence of all these
> apps to be severely rewritten, Alan. Not acceptable
> by any means.
>
> What I want to a later advocacy of FB adoption is a
> DB-only migration. Rewrite the SPs and nothing more,
> which would cost a entire month or even two of heavy work
> OF ME and maybe more one. Believe me, is much
> faster to achieve than make the boss buy the idea of
> creating a 3-tier module.

The it sounds as if you have not designed your software correctly from
the start, and any client/server database will have trouble handling
things. Just because some engines offer a function, it does not mean
that it will actually work efficiently. Consider the problems of
managing a multiple query across three or four machines and getting any
sort of speed of response. SOMETHING has to handle that at a higher
level if it is ever going to work, and the third tier is the way to do
it. Now if that is built into the engine it could be nice, but becomes
VERY restrictive.

IF all the data is on a single machine, then there is no problem having
it in a single database! I came from dBase and was used to having
separate files for each table, so started by building separate databases
for sections. There are still separate databases for some areas, but the
main work is always to the one database, with information gathered from
others replicated as required. THAT can then be managed between
different machines as required, and does not get slowed down while
waiting for network data transfers.

SO look at the problems of what you are asking for and consider the
amount of work required to implement that with the same flexibility that
Firebird currently supplies. Look at how others do it, with block copies
of raw data between machines, and consider the performance implications.
Can you manage those block copies better since you know WHAT data you
want and how to configure it.

Get the structure of your data right first and work out what you need
THEN perhaps you can design a better application? A number of things we
got used to in the past have been lost over time as other requirements
take over, so we have to rebuild things with the result that overall
performance improves. I never provided a monthly view of data on the
dBase systems, simply because the time to create it took too long.
Firebird builds a year view in not much more then the time it takes to
click the button and those results are replicated to a central database
that in the past would have to have reviewed all the machines and all
the data to achieve the same result.

Hopefully you get the jist from this that I can't see the need to spend
time on creating yet another complex layer above Firebird. Lets get the
core engine totally efficient and powerful - working on a single machine
(which may well have multiple processors) and create the interface for
the next tier so that we can all build the applications we want ;)

I then use PHP over the top of that and can talk to data on ANY engine,
on ANY other machine and pull it back to Firebird to do the real work -
it works a dream :)

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services