Hi Nando,

> >> 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)

True.

>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.

True.

>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. ;-)

It all depends on your requirements and your amount of time.

That being said, if you lay out your requirements, we can think
of naming some componentsets :-)


With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com