Josh,

At 05:13 PM 18/07/2003 +1000, you wrote:

>I have attached DFM code and the pas too

The list doesn't accept attachments. You can paste the DFM code of the
small group of objects into an email. I don't need .pas code right now -
the first thing to look at is how those properties have been set.

> > Also, don't use TIB_Query for update SQL. It's too wasteful. Use
> > TIB_Cursor or TIB_DSQL.
>
>Thanks for this hint - Now I have a few hours work to do to change a couple
>of hundred TIB_Query's to TIB_Cursors :-)

I'm curious to know why you have "a couple of hundred" update objects in a
single application.

>Supposing I was executing a procedure (one without suspend statements),
>would you suggest TIB_Cursor or TIB_DSQL?

I always use TIB_DSQL for executing "Execute" statements, whether they are
SPs or DSQL. You can pick up any return values you want via the Fields[]
property after execution.

That said, I might not have more than one or two separated DML operations
in an enitire application. An example of where I might use one is where I
have a lookup set in a KeySource/Lookup relationship and the user wants to
add another lookup row. Rather than interfere with the lookup dataset,
I'll use an ib_sql with input parameters for this purpose.

For regular DML operations related to the current row of a dataset
(TIB_Query or TIB_Cursor) I use the xxxSQL properties to do updates,
deletes and inserts - and then only if RequestLive isn't applicable to the
set. That's how IBO is designed to work for the 98% case. My attitude is
"Why keep a dog and do the barking yourself?"

Helen