At 05:13 PM 25/08/2003 +0000, you wrote:

>Hello,
>
>--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
> > At 03:48 PM 25/08/2003 +0000, you wrote:
> > >Hello,
> > >
> > >I have two parametrized queries (TIB_Query components), one is
> > >UPDATE, and the other is SELECT.
> > >First one works perfectly:
> > >
> > >UPDATE
> > > TABLE1
> > >SET
> > > FIELD1 = :FIELD1
> > >WHERE
> > > FIELD2 = :FIELD2
> >
> > Except TIB_Query is the wrong component for a DML query. Use
>TIB_DSQL or
> > IB_Cursor.
>
>What exactly constitues incorrectness of using TIB_Query here?
>What I gain using TIB_DSQL instead?

It's not what you gain, it's what you lose. :-))

A dataset is, by nature "fat client". The scrollable dataset (TIB_Query,
TQuery) is the "ultra-fat client". As well as a row buffer, it has
gazillions of member properties and methods that are not required for
DML-only queries.

TIB_Cursor is a non-buffered dataset. It is leaner than TIB_Query but,
though still quite fat, is the class of choice when you want a row context
for DML.

TIB_DSQL is not a dataset at all, so it is the class of choice for DML-only
queries that don't require a "current row" context, i.e. as in your
example, where you are cooking up DML on-the-fly.

So, while tib_query works for practical purposes (does the job), it does so
at the expense of unwanted pounds. The aim with clients for client/server
systems is to "think lean".

Helen