Subject Re: [IBO] Problems with Keylinks
Author Tony Masefield
--- In, 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
> 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,
> immediately step into a very abstract world where you target not
> but sets of data. The means to access the abstract stores is a
> language (of which IB supports two -- or three, if you include its
> 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
> 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
> 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*
> So knowing SQL as well as possible is essential. You can't cop out
> this. IBO provides TIBOTable to help with the transition when you
> an existing BDE application. TIBOTable surfaces work-alike
behaviour but
> it doesn't operate on client-side disk tables: it performs some
> costly SQL under the hood. One doesn't write viable applications
> 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.