At 08:01 PM 29/09/2007, you wrote:

> > On the other hand, if your SP is executing some DML in addition to
> > feeding out rows to the output buffer --- a highly NOT RECOMMENDED
> > thing to do --- then you will have a genuine need to use Rollback to
> > end the transaction.
>
>Exactly, my SP executes some DML and after every DML command it does a
>suspend to give a callback to the client. Why it is not recommended?

Most often, people use SSPs to provide datasets to give a view of
data state. Mixing DML with a dataset means you produce results that
don't exist, except as the result of changes that might be rolled
back. You cannot, of course, do a "refreshed" view of any data that
was generated from an SP that performs DML.

Using it for only the purpose of callback (no user data change
decisions based on the output) is fairly harmless.

>In my case a TIB_Query would be better as Alan suggested.

Agreed, that would be a bit simpler to manage. The records are still
buffered one by one at the server but, if the number of rows is
small, you can keep a small number hidden until the SP completes.

From a performance POV it's certainly an effective way to slow down
your operation. Rather than using this approach to feed a progress
bar or whatever, I'm much more comfortable with running an executable
procedure in a IB_DSQL, that returns a summary upon completion...or a
simple exception if it fails. Fast execution, no cleanup to do, and
you can do a simple character animation in a status bar to emulate a
progress indicator if your users want feedback.

Helen