Martijn,

>> eg: do you need to access multiple different database engines
>> from a single codebase?
>>
>>> Yes, I need.

M> I'd say that any Firebird specific component set can be
M> thrown from the door then.

That's not always true. I have found that native components are often
the "best" (read as most performant and less buggy - feature count is
almost irrelevant in a generic scenario) way to access a particular
database from Delphi. Building a framework that encapsulates these
native components (or learning to use a pre-built one) is not an easy
task but is very rewarding in the end. Generic frameworks like the
BDE, ADO and dbExpress have been, in my experience, less generic than
advertised (try to define persistent numeric fields with Oracle, MS SQL
Server and Firebird for a sample of what I mean).

Plus, the need to support multiple backends extends beyond the
access component set. SQL dialects, transaction management (esp.
different meanings of apparently similar transaction isolation levels)
must be taken into account. I have found that when people realize all
this, and aren't prepared to leave the simple RAD dataset-based
approach they are comfortable with in Delphi, more ofthen than not the
requirement to support multiple database engines just disappears. ;-)

Ciao
--
Nando Dessena
mailto:nandod@...
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================