I'm in a savage mood this morning...

> TIBTable is not to be used. Use Queries etc. Works just fine.

TIBTable is also based on a query ancestor class. It just does a brain-dead
SELECT * FROM ATABLE and leaves you with a plethora of records on the client
to deal with locally. It's the same problem if you use TIBQuery with that
same brain-dead SQL statement.

What you are really saying here is do all the work manually that TTable used
to do for you. To some that is not an attractive proposition and I don't
blame them. TTable would do a lot for you if you knew how to use it. Why
should they take a step backwards in encapsulated capabilities?

> Probably TIBOTable is not really a table but a query.

Anything returning data from a SQL based back-end is done using a query.

The difference is TIBOTable has multi-queries and intelligent buffering. IBX
compares like a 4 cylinder engine with a single gear transmission to IBO
which is like a 12 cylinder engine with an overdrive transmission. If you
are in a race, which car would you prefer to drive?

Let me explain a few things... First, a little history:
There are a heck of a lot of good reasons people used the TTable component
with SQL back-ends. TTable has some unique and very powerful capabilities
that weren't obvious and if you didn't carefully make sure things were
configured properly it would be a slow dog. If you knew how to use TTable,
it was the only component to use in a lot of situations. Especially with
very large tables needing random and/or filtered access. All of this
nonsense I see about how people should NEVER use TTable makes me want to
vomit. They are ignorant, period.

IBO implements every benefit people who knew how to use the TTable component
expect and at the same time it irons out all of the wrinkles the BDE imposed
that would drive people crazy. In short, with IBO it is VERY easy and
efficient to use the TIBOTable component and it deserves to be recognized
for such.

If you are going to argue about not wanting to return all columns, that is
what a VIEW is for. Or, I made it so you can have all the nice benefits of
the TIBOTable component in the TIBOQuery with a little additional tinkering
to have the ultimate control, functionality and efficiency. Yes, that is
right, my query has all those benefits available as well.

In short, the difference between IBO and IBX is that IBO has a lot of fine
tuned machinery under the hood to make your job a whole lot easier. IBX
leaves most all of the work up to you. In today's rapid paced environments,
I think it ought to be obvious where your application (and learning curve)
is best founded.

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