Myles,

Sorry, I thought you meant to add some additional processing in the front
end to catch the exception and provide some message handling. This is just
going to be run via Wisql or IBConsole or somesuch.

The other problem with exceptions is that I want subsequent tables to
processed within the stored proc. If I raise an exception, that interrupts
the sp with no change to continue. I just want an indication as to which
table failed to be processed and why.

Bob M..



At 5/24/2004 02:05 PM, Myles Wakeham wrote:

> > On 24-May-2004 10:53:59, Bob Murdoch wrote:
> > There's no front end to this, it's just a utility procedure to be run
> > manually on a very infrequent basis. I was just looking for a nifty
> > function that I might not have been aware of that would provide a better
> > message to the user.
>
>Not sure I understand what you mean here. If there is 'no front end' to the
>procedure, then how is it run? If no one fires it off (ie. Its from a CRON
>job, trigger, or something like that), who get's the error message? Seems
>that if no front end is there, then no one would be able to read any error
>message either.
>
>If a user fires it off, then there has to be some user interface here.
>Hence raising an exception should be able to be handled by that user
>interface.