Helen, I have a question that you may just not have the time or
inclination to answer. And it's going to sound provocative but I
certainly don't mean it that way. Every database application I've
ever written was via the VCL and I know very little about database
APIs and mechanisms beyond that. But you make the statement, "This
model is therefore hopeless for a client/server DMBS If the table is
bigger than about 200 rows." The application that I'm porting was
originally written in Delphi using the BDE against a Paradox
database. I decided some years ago that I wanted to move to IB so I
stopped deriving directly from TTable and derived instead from a
class I call TPortableTable which handles the little differences
between Paradox and IB. TPortableTable derives from TTable but is
sensitive to whether the back end is Paradox or IB. What I'm
working on now is making TPortableTable derive from TIBOTable. My
first cut of moving to IB was to migrate my data from Paradox to IB
and then continue to use BDE through the Gemini ODBC driver. That
implementation has been running in production for something like
five years now and the tables in my database have way, way more than
200 rows. The table against which I was doing the operation above
has, as of this moment, 2,356,043 rows, and all the others in play
have on the order of a million or so rows.

Now, why is it that the rather hokey mechanism of TTable->BDE->ODBC-

>IB can do these operations correctly and efficiently, but IBX and

IBO seem to stumble? My BDE app doesn't chew up tons of memory. It
doesn't chew up tons of cpu cycles or disk reads. And I had to do
very little porting when I converted from Paradox to IB. Since then
I've been slowly moving myself away from dependence upon BDE. I
haven't used Paradox for this system for years, so we can't really
blame any performance or resource issues I'm experiencing on Paradox-
friendly things that I may be doing. One would think that TTable-

>BDE->ODBC->IB would be full of performance problems and hiccups,

but I've experienced far more hiccups trying to go to TIBOTable->IB
and I completely gave up on TIBTable->IB. How is it that the BDE
which was written years and years ago seems to be able to handle
these things better than IBO? I mean, when I do the
Insert/Post/Edit/Post against TTable->BDE->ODBC->IB against a table
with hundreds of thousands of rows, it just works and it doesn't use
a lot of cpu or ram or disk to do it. But when I run this same
sequence against TIBOTable->IB, suddenly now I'm blowing up, I have
to change this or that setting, and I won't be correctly positioned
in the cursor after the Insert & Post. How does the BDE pull off
this magic? The same is true of things like FindKey. I do lots of
FindKeys in TTable->BDE->ODBC->IB and they all just work. But in
TIBOTable->IB, he does huge amounts of caching and then linear
searches through the cache.

I have an app that has worked fine for years with big tables,
TTable, IB, BDE, and ODBC and no Paradox. I think it was perfectly
reasonable of me to assume that removing BDE and ODBC from the stack
would only result in increased speed and simplicity, but this hasn't
panned out very well. What have I missed? Why is it so hard for
TIBOTable->IB to perform at least as well as TTable->BDE->ODBC->IB?

Thanks,
Kevin Donn