At 07:18 AM 7/06/2004 +0000, you wrote:

> > Oh, that! All that is, is IB_SQL calling FETCH NEXT and there is no
>NEXT
> > because the cursor has reached the end of the set. That's the tool
> > itself: the DSQL tab can only handle executable statements or select
> > statements that return singletons (like SELECT MAX() or a select on
> > rdb$database. So it performs a NEXT on the result to check that the
>result
> > is a singleton, and permits it if it gets that errorcode back. You can
> > write exception handlers like that yourself...
>
>Yes I do, but I don't surface them publicly!

Why do you think IB_SQL does? I'm afraid that if you think reading the
monitor output is a way to handle exceptions in your applications, you have
many sorrows ahead.

>As a matter of fact it was a dsql error, and getting returnvalues doesn't
>insure the call din't leave a mess just waiting make your life miserable.....

Do you want to elaborate on that? Do you understand that getting return
values from your request is a signal that the query succeeded, i.e. it ran
without exceptions? The fact that the utility deliberately raised (and
handled) an exception to enforce a usage rule does not in any way indicate
that your query failed. Nor, indeed, did it indicate that your query "left
a mess".

Or is this just how you are when you are happy? :-))

Helen