> 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

sounds like all you need is a few interfaces to start breaking away from old
code. You say you are now optimising for both environments so whenever you
start one of these optimisations, create an interface. The paradox setup
will use the paradox side of the interface, the new firebird setup will use
the firebird side of the interface. I can even imagine you being able to
install and maintain a hydrid system for a time on client's machines until
you finally migrate them and all the interfaces over.
Alan