Thanks for the guidance, folks. I've said this before, but I feel I
must keep saying it so that people don't forget and so you don't
completely feel like you're talking to a wall: I know I'm not using
IBO in a good way. Eleven years ago, doing my first database
application, I made the decision to treat TTable as a fundamental
object in my architecture. I didn't have much database experience
but I had a lot of OOP experience. Because it wasn't practical or
affordable for my customers to have database servers at every
installation (this was 1995 remember), I had no choice but to use
Paradox. Although there was no TDataModule at the time, I could
have instantiated all my tables in a collection of some kind and put
all my business logic there, but I thought it made more sense to
represent every table in my database by subclassing TTable. This
has worked very well for eleven years and has been extremely
flexible. I've now got hundreds of users some of whom must stay on
a Paradox database and many who must move to something more robust
like Firebird. I'm pretty amazed that I've been able to make the
same code base, hundreds and hundreds of thousands of lines, compile
in either Paradox or IBO mode. All of these systems also interact
and the IBO systems must continue to play nice with the Paradox
systems.

So I know it's irresistable to keep telling people to leave their
Paradox ways behind, and believe me, I'd never develop new code this
way, but I hope you can understand that it isn't always possible. I
can't just stop developing this app - it keeps six people gainfully
employed; and I can't just convert the entire thing over to IBO
because it must continue to run on Paradox in many places; and I
can't just convert it to using all good client/server techniques
because that would break the Paradox stuff. The *only* thing I can
do is identify the parts that don't run well and optimize them for
both environments.

The particular piece of code I'm working on right now is a low level
routine that reads in serialized tables. The procedure accepts a
table as an argument and is expected to fill it from a stream. It
is called by God only knows how many higher level routines. Those
routines *might* have put event handlers on the passed in table, so
it *might* not be possible for me to simply use a TIB_DSQL. If I
can make the TIBOTable work fast, that will certainly be my best
bet. If I can't, I'll have to scan the entire codebase and make
sure that no caller of that routine puts handlers on inserts or
overrides any of the virtuals. That's a big job. I'd rather not
have to do it.

So, bottom line, don't give up on me. I'm not a complete fool. I
made some regrettable decisions a long time ago that I've
unfortunately (or fortunately depending on how you look at it) built
a thriving company on. I promise not to make any more bad
decisions :-)

kd