On Sunday 16 February 2003 21:44, you wrote:

Hi,

> > If you want your app to use more than one 'backend', not just
> > FB. If you are only developing for a single 'database' a
> > native component set is always better IMO.
>
> Right. But what are the specific reasons a native component
> set would 'always be better'?

Its more that 'generic' componets are worse, than native being better. With
generic components, you are always working at the lowest common denomenator,
where as 'native' components give you full access to all the features of
RDBMS you are using.

The biggest thing for mean, is every RDBMS is different, requires a different
way of working, and have different 'quirks'. A piece of code written and
optimised for Firebird, may work poorly for Oracle, and visa versa.

> In the case of dbExpress vs. FIBPlus/IBO/IBX, how big a speed
> improvement does one get for the latter

Speed improvement is not the real big issue, native components are not going
to be that much faster in them selves, but because they allow you to write
'for the engine', you can utilises all the features and quirks to get all
the performance out of the engine.

> I'd like to know if the advantages of native components are
> worth forgoing future backend-flexibility for.

Its all down to flexibility. All database engines are different, they all
have good points and bad points. What might work well as a simple select in
Oracle, may need a Stored procedure a specific transaction setting in
Firebird, what might work well as a simple insert in Firebird, may require a
tempory table or two in MS-SQl, you get my-point?

As for 'backend-flexibility', even with native components, a well designed
arcitecture can easilly handle that

Phil
--
Linux 2.4.4-4GB
8:55pm up 34 days, 2:44, 1 user, load average: 0.24, 0.13, 0.04