> 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 think this is essentially what I've done, although I haven't
greatly used interfaces, but I'd be interested in a little more
detail. The specific case I've been working on is a call with this
prototype:

procedure ReadIntoTableWithFields(var f: file; table:
TLWPortableTable; extraFields: TExtraFields);

My implementation of TLWPortableTable looks essentially like this:

TLWPortableTable=class({$IF Defined(IBO)} TIBOTable {$ELSE} TTable
{$IFEND})

Originally my app liberally used TTable and had many classes that
inherited TTable. When I began my conversion to Firebird, I
converted all references of TTable in my app to TLWPortableTable.
Then I started filling in the gaps that TIBOTable doesn't provide
for, e.g. that Firebird index names are global rather than within
the table's namespace, that IBO doesn't have RenameTable, that IBO
can do ranges far faster than it can do FindKey, that there's no
support for BatchMove, etc. Repeat all of the above for TQuery,
TIBOQuery, and TLWPortableQuery, not to mention TLWPortableDatabase,
TLWPortableDataSet, & TLWPortableBatchMove.

Eventually I got a system that would compile with {$DEFINE IBO}. A
while later I got a system that would run. Now I'm working on a
system that runs well. Mostly I've put all my work into making
TLWPortableTable handle all the differences between TIBOTable and
TTable. I've got a single unit, PortableTable, that handles more
than 95% of the differences between IBO and TTable/Paradox. Every
time I run into a case that doesn't work or doesn't work well, I
first try to handle it generically in PortableTable. As a last
resort I'll handle it out in the codebase where the problem actually
occurs, but this gets me into the bad situation of dealing with
problems on a case-by-case basis. Which brings me back to the case
in point, ReadIntoTableWithFields.

So how exactly would you apply your approach to this particular
problem?

Thanks,
Kevin Donn