--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:

> 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

I didn't say that

query "left

> a mess".
>
> Or is this just how you are when you are happy? :-))
>

Sorry, I don't use emoticons out of principle, but I like your humor.
But when I write that I disagree with you on this matter I'm glad
Providence created Down Under.