At 05:33 PM 26/07/2005 +0000, you wrote:

>Just to say once again Helen, "Thanks for the enlightenment".
>At this point IBO TDataSet is working fine and I'm starting to
>(slowly) get the hang of things.
>My original conjecture was that IBO would form an 'absolute' link
>between Pascal and the clinet server architecture IRO the change
>from desktop to CS - which it doesn't, one still needs a fair
>grounding in SQL. Guess I'm getting lazy in my old age!

If you're making the leap from desktop database to Firebird/IB and from the
BDE to IBO in one, the curve is certainly much steeper! The TTable was
designed for use with Paradox tables - being a disk file with a number of
lines in it that the BDE (a.ka. Paradox engine) treats as "records". Other
ISAM databases (dBase, Access, MySQL, to name a few) are also these
file-based datastores.

When you get into a serious RDBMS designed for multi-user concurrency and
managing its own physical structures inside a single logical file, you
immediately step into a very abstract world where you target not tables,
but sets of data. The means to access the abstract stores is a query
language (of which IB supports two -- or three, if you include its binary
language representation, or BLR). The API surfaces SQL directly. Most of
the structures and functions in the API are designed to interpret SQL. All
DML statements target sets. All SELECT statements return sets (not tables!).

The BDE for InterBase, Oracle, MSSQL is a crock. In order to work, it has
to interpolate the Paradox engine into the interface layers. This engine
is not an SQL engine - it uses a proprietary query language. So, for the
BDE to work at all with any other database, it has to grab sets as they
come across the wire and create *Paradox tables* on the client's hard disk
to put them into. The TTable is designed to work with *these* tables.

So knowing SQL as well as possible is essential. You can't cop out on
this. IBO provides TIBOTable to help with the transition when you convert
an existing BDE application. TIBOTable surfaces work-alike behaviour but
it doesn't operate on client-side disk tables: it performs some very
costly SQL under the hood. One doesn't write viable applications for
Firebird/IB based on table components.

I could rave on....but I gotta get a life! <g>

Helen