> > 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

I appreciate your detailed description but I'd have to say that I would need
to know a lot more about your project and your code base to make really
usefull directions on this matter.
That said - If you haven't worked with interfaces much you'd need to do some
reading first.
I would start looking at

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

and thinking along the lines of where you can make the switch from table to
query. You could write the implementation of this procedure such that the
first thing it does is translate the properties of a table into the
properties of a query.
then you call

> procedure ReadIntoTableWithFields(var f: file; query:
> TLWPortableQuery; extraFields: TExtraFields);

Thus you have the interface... you can call the second proc directly more
often as your code base matures. This first call may require modification to
pass additional propertiesin the first instance.
I would also think along the lines of abandoning reliance on the IBOsets and
move to IB_sets in the same steps.

Alan