On Sun, 27 Feb 2005 08:23:16 -0500, Doug Chamberlin wrote:

>
>There is really nothing fundamentally wrong with building your application
>the way you have but given your design you *do* severely limit your ability
>to change databases easily. If current Firebird does not fit your
>application structure, then Firebird may not be a candidate for your use.

I'm really tired of MS SQL and FB, EXCEPT FOR THIS, it exceeds most of
the requisistes our customer have, if you cared to read the end of
message you'd read that FB really managed to basicly ban MSSQL
and Oracle from most of new projects on Navy.

>Unfortunate for both you and the Firebird team, but nothing to lose sleep over.

No, but I do lose sleep concening about concurrency issues that on
FB I do not need to worry at all.

>
>I don't think the Firebird team should worry about enhancing its database
>to handle your design needs.

Only mine, white face?

I'm not alone on this, Doug. I can assure you. If I hadn't saw this
thread and similar threads on support list in Portuguese, I would never
had
open my mouth on this thread. I'm not a lone voice on desert as you
trying
to figure.

> Firebird cannot be SQL Server and should not try.

The only good thing about MSSQL2k engine, and what we don't have on
FB and is only attainable using application code is multidb server side
SQL queries.

Remove this advantage and it become a clunsy and badly disguised
lock&log engine with loads of add-on things around to make this appear
"professionally made". But it'll last until MSSQL 2K5 which implement
record versioning.

We have dynamic SQL, and I was pretty sure that were MSSQL dbas what
start that advocacy. We'll discussing temp tables on Architect list
and Ann only gave up the idea of SQL standard temp tables be
implemented
first because of advocacy that SPs must be able to create temporary
datasets. And she proposed something really amazing - transient
datasets,
an elegant and very brightful feature that makes MSSQL funcionality
almost *obsolete*. When implemented it'll give us a feature which will
edge the MS thing.

When your system have to cope with diffent nature data, and this must
be mantained interdependant, not on one only monolithic database, the
ability to create queries and (specially) sps able to talk to both dbs
makes
your like MUCH easier. No need 30000 lines 3-tier module or anything
like that
just make one db communicate with other. The app code does not need to
even know of the existance of that communication.

If we have this edge today, and with the robustness and concurrency
edge of FB over MSSQL - life will be much easier to convince people to
move to
FB and you can say "there's nothing that a skilled MSSQL dba can do in
SQL that we can't in FB - and our db engine is much more robust and at
no costs".

But since MSSQL2k5 is to appear more day less day and certainly
the vulcanizing of FB2 would not terminate before it, our robustness
argument will be seriously weakened. It's a threat and a threat from
MS is really to not be taken lightly.

We don't need to follow MS standards (like [] instead of "" for
delimited
identifiers) on its weakenessses. We're the second more used OS
database
on the market and the only capable of menace robbing their user base
(remember my BC on Brazilian Navy on last message) in the long term.

FB exceeds all other requisites WITH LOUVOR, except that.