At 07:01 PM 30/09/2004 -0700, you wrote:

>I am starting to be of the opinion that the best option is to just use the
>GDS32.dll directly. The components are cute, and work well for
>prototyping, but they appear to be lacking adequate stability for serious
>enterprise scale uses, IMHO.

Sounds a fairly uninformed statement...

>Also bear in mind that the timestamp conversion function in gds32.dll
>drops the milliseconds, so you may want to write your own replacement for
>that.

That is not necessary. An external function GetExactTimestamp() is
available in the fbudf library which is deployed with Firebird.

>It's not a big deal, but it'll save you a lot of hunting when you know in
>advance that the fractional seconds are truncated at the GDS32 layer from
>all times that are stored.

Actually, they are truncated on the server - a kind of "lowest common
denominator" to genericise the return value to support OS's that can't
return subseconds. You can store subseconds down to ten-thousandths of a
second and, if you do, the server has no problem processing them and the
client has no problem returning them to the application. It seems to me
you are deriving a lot of your "wisdom" from using bad client tools...

> worst case). Firebird appears to keep its indexes
> well balanced because there was no observable
> performance difference between that experienced
> following an insert of 4,000,000 rows and that
> experienced after dropping and rebuilding the indexes.

It's not always the case. It depends on the index.

> Caution: Beware of the DBXpress and IBXpress
> components used by some Delphi and BCB apps. My
> testing has exposed memory leaks and other serious
> issues with the middle layers,

Agreed, both of these layers have been very poorly architected.

>and the Delphi VCL
> architecture imposes minimum 3% maximum 30% overheads
> on top of the database performance.

That's misleading. The VCL architecture + the Borland implementations for
generic (vendor-independent) data access cause such problems. The
Firebird/IB world is richly provided with vendor-specific connectivity
layers between Delphi/Kylix/BCPP that -- to varying degrees -- avoid the
overhead imposed by the generic VCL data access components. Anyone
considering using the Borland client development environments owes it to
him/herself to evaluate the best of breed from this comprehensive collection.

> The MAX, MIN, and Count operators are not as well
> optimized as they could be either. MAX and MIN can at
> least be optimized somewhat be ascending and
> descending indeces where they are required. Count on
> an entire table will always do a table space scan.

That is true; and it behoves the developer to learn the language and
discard a lot of the itchy old tricks that s/he used to have to resort to
in MSSQL. RDBMS's are not meant to be dependent on storage row order so
systems that don't support important relational language features like
existential predicates have to store row-counts and compromise multi-userness.

It's a source of comedy to look at so-called "benchmark tests" involving
MSSQL and other DBMS's that poorly implement standards, again Firebird and
others that implement standards better. There is always a "SELECT
COUNT(*)" test in there that the lemmings take to be an indication of
comparative performance. It says nothing about performance, of course, but
it is a self-documenting commentary on the competence of the test designers.

> Helen is the real authority

Actually, not, I'm a messenger. The real authority is Ann Harrison.

/heLen