Fabricio Araujo wrote:

>>(I still think your argument sounded like "My app is designed to require
>>this and therefore I think Firebird should have it so I can avoid
>>re-design".)
>
> Me and a lot of people that like to physically isolate independent
> and diverse constraints database (constraints = requisites).
> I have one db that I backup one time at week. And the other
> during the simulation are backuped to create point-in-time
> restore (like a save game feature) Plus extra auto backups a day.
> In a week there's commonly from 20 to 40 backups.
>
> Since each simulation scenario goes to a db, disk space wasted
> is not a problem. If I merge the 2 on a (teorical) FB migration, each
> simulation will go to point that we generate GB and GB of backups!!!
>
> Is not only this - the maintenance would become enormously
> increased... And me, actually not working overnight, will became
> a true vampire.... ;-/

But at the end of the day I *STILL* see this as a third tier! We need
some feedback from the gurus, which is why the discussion should be on
firebird-architect. The processing that is currently being worked on is
'packaged' in a processing engine based on a single entity of hardware
with a single file system structure. In order to get two different
machines (with potentially different OS's) working together, we need
another layer over the top of the engine(s) which carries out THAT
processing, but which is not so relent on direct access to the file
system? As I understand the Vulcan structure, that layer could be across
different engines altogether, by using the right 'module', but at the
end of the day it is just the integration of an external tier that is
currently available of the shelf in a number of ways. MSSQL just hides
that fact, in the same way that BDE did in the past. As we now know BDE
was a dead end because of the way it implemented cross engine functions.
By designing our own 'layers' we have much better control and can 'see'
what is going on.

Don't take this as my being anti the principle. I am only trying to get
people thinking about what is involved, what the range of requirements
is, and why it is NOT a show stopper for many of us who manage to avoid
the 'hole' in the first place ;)

Just sheepishly following MSSQL could end in the same hole as BDE - so
just think about how you COULD do without an integrated tier, and
implement it externally as it may result in a much faster performance
and could mean that you could progress in stages using both MSSQL (and
other engines) and Firebird in parallel as many of us already do. The
information obtained would then help to move Firebird 4 ( because I
think THAT is how far way it is ) in the right direction, but allow
progress towards that end now.

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