Chris,

> > If you are using the TIBOTable component it will simply do just as
> the BDE did.

I should also say that it will be much more flexible/versatile than the BDE
was too. TTable was excellent with InterBase as long as you knew how to use
it. There were very narrow margins of use to keep it in an efficient mode.
It was so inflexible that most people had no idea how to use it at all and
that is why so many people trash-talked it so much. IBO will be a lot more
flexible. I'll divulge all the details at a future time. Gotta get it
finished first. <g>

> This interests me. I assumed (without ever investigating it further)
> that the TIBOTable component was only there for backward
> compatibility and its use would most likely result in a major
> performance penalty like in IBX. Is this not also the case with IBO ?

This is not at all the case with IBO.

> The BDE/Paradox app that I am converting makes very heavy use of
> TTable components and I have been converting everything over to
> TIBOQuery and/or Native components. Would you recommend this strategy
> or is TIBOTable usage an acceptable practice in the IBO community ?

Even though I am accommodating the desktop "spreadsheet" style access to
data I do not feel to promote it above a more client/server friendly
application design. It is not only much more efficient for the network, etc.
it is much more efficient for users. I find it amazing that people are
willing to scroll and sift through so much "noise" in order to find the
record of interest when is all they would have to do with client server is
type in a little search criteria and tell the server to go get it.

> Is there a noticeable performance penalty or higher then normal memory
> usage when using TIBOTable ?

No, not really. It does use a little more but it depends mostly on you
database design. My queries will also be able to use the horizontal
refinement just as the TIBOTable component will (unlike the BDE). So, feel
free to continue converting to queries.

> > So far the only hang-up is that if you are using more than one
> column InterBase doesn't seem to optimize if all that well. Ann
> Harrison is onto the bug for it and hopefully the initial release of
> Firebird will have it resolved.
>
> What exactly do you mean by this. Are you talking about having more
> then one field in the ORDER BY clause of the SELECT statement ?

Yes, you got it.

> > Hope this is what you were looking for.
>
> Exactly what I was looking for (and then some).
>
> > E) Addition of various modules for full text search, service
> applications, simple replication, PDOX to IB migration tools, and
> possibly more.
>
> Having written a program to convert 250 Paradox tables over to IB, I
> would be interested in seeing your version (when it arrives). So far
> this was probably the toughest part of the entire conversion. So many
> valid field names in Paradox are now reserved words in IB. Field
> names in Paradox like "TotalValue" look pretty nasty when they get
> converted over to TOTALVALUE. I ended up converting it over to
> TOTAL_VALUE so that I would have better read-ability in code. AutoInc
> fields need to be converted over to generators with the appropriate
> triggers and the list goes on.

Yes, there is much that can be done. This won't be released for a while yet
I'm afraid. I would like to have it done in time for the workshop I'm doing
in Germany the first part of March but I think I'd be pushing it.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com