--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:

> 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

Thanks (yet again) Helen. With so many things in life wish I
had 'taken the leap (RDBMS)' earlier but I had had no reason to go
beyond Paradox desktop apps. As I am starting some new apps, have
taken the advice (copious) to keep away from 'Tables' (or anything
that causes too much network traffic) which is why maybe I have
sometimes come adrift.
On the surface SQL seems somewhat easier (maybe even more logical)
than C, C++ or Pascal - at least there appear to be fewer keywords!
Something of a 'paradigm shift' (overused) from programming
languages per se.
Thanks for the info on the BDE, I knew it was problematic but not as
bad as you have now indicated.
Starting to get 'daring' with IBO now with great success (for a
newbie) thanks to your help.