Carl Reynolds asked:
> >Um, as far as I know, this is a problem with ANY SQL-based DB
> (oracle et al).
>
> There's abysmal and then there's merely appalling. :)
>
> What surprised me is that a simple "select * from tablename" TQuery
> performed so much better than an equivalent TTable, in Interbase. Can't
> really compare this to other sql-based db's as they're not
> available to me.
We (Profax) have been all through this one and back again. The first
culprit is the BDE itself. If you want to have a look and see how the BDE
manages raw based table compatibility against a SQL back end, fire up the
SQL Monitor and have a look at the gargabe that it generates!
In general the BDE creates and uses three (3) cursors to navigate through
a SQL table, and the overhead of continually reparsing them, walking them
and otherwise muching about gives you this massive slow down.
The second hit is in the design of the TTable, which has various row table
based assumptions that cause a lot of extra fetches from the back end. Not
a problem if you are loading from a file system but the extra selects
generated really kill performance.
So the general solutions are to a) not use TTable against SQL backends, b)
not use the BDE or c) write TDataSet derived classes that map better to
the SQL model. The archives are full of this question getting bashed about
is various permutations, and I would suggest some archive trolling for
suggestions on better use of the BDE in this sort of situation.
Cheers, Max.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
