0

I have a loop which executes a proc. That proc can throw RAISERROR which, of course, stops the loop and the whole program. Is there any way to ignore that error and continue the loop? In normal languages I can CATCH the error, but what is possible in Sybase T-SQL?

I found EXCEPTION section (similar to Oracle) and CONTINUE_AFTER_RAISERROR, but they are in Sybase IQ, not in ASE.

Any idea?

markp-fuso
  • 28,790
  • 4
  • 16
  • 36
Ursego
  • 141
  • 1
  • 6
  • generally speaking it will come down to two items ... 1) the severity of the error (not all errors will 'stop' the T-SQL batch/loop) ... 2) how the T-SQL code (or client software) responds to the error; at a minimum you should update the question with the complete error message(s); at this point it's not possible to tell if the code is 'stopping' because of the error severity, something in the proc that says to 'stop', the parent loop that's causing the 'stop', or the client-side application that's stopping because of its default error handling ... – markp-fuso Dec 08 '22 at 23:15
  • re: that last item ... client-side application that's stopping the processing ... where are you executing the loop from? the `isql` command line tool? a GUI? custom software/script (eg, C, C++, perl, python, shell, something else)? if you're executing from somewhere other than the `isql` command line tool ... what happens if you run the loop from within the `isql` command line tool? if the code does not 'stop' when run from `isql`, but does 'stop' when run from some other client-side application, then it sounds like the issue may be with the client-side application's error handling – markp-fuso Dec 08 '22 at 23:18
  • "the severity of the error (not all errors will 'stop' the T-SQL batch/loop)" - It's RAISERROR written in the proc (not a built-in error of Sybase). I cannot imagine how RAISERROR will NOT 'stop' the T-SQL batch/loop. – Ursego Dec 08 '22 at 23:22
  • "how the T-SQL code (or client software) responds to the error" - There is no client app. It's a proc which is run manually (with EXEC) and populates a table which will be used for an ad-hoc report. – Ursego Dec 08 '22 at 23:25
  • "at a minimum you should update the question with the complete error message(s)" - RAISERROR has the same behaviour regardless what is passed to it as the error description parameter. – Ursego Dec 08 '22 at 23:26
  • "where are you executing the loop from?" - From a home-made code editor named SPA (stored procedure administrator). I don't think somebody heard of it outside my company. I believe, it uses isql internally. – Ursego Dec 08 '22 at 23:29
  • by itself `raiserror` does *not* cause processing to stop; it's not uncommon to see a series of nested processes (procs, triggers) coded to generate their own error message(s) when unwinding from a faulty operation (thus providing a pseudo-stack trace); if your code really is stopping then there's more going on than just a user-coded `raiserror` – markp-fuso Dec 08 '22 at 23:32
  • this `SPA` you mention *is* your client-side app; try using the `isql` command line tool that comes with `ASE` to run the `EXEC` and see what happens; the `isql` command line tool does not have any special error handling capability ... it's basically a pass-through from you to dataserver and back; in `isql` the following does *not* halt processing: `raiserror 19001 "this is a test"`/ `print 'hi'` / `raiserror 19002 "this is a test"` / `go` / `print 'bye'` / `go` ... it generates: `Msg 19001...` / `hi` / `Msg 19002 ...` / `bye` ... processing is *not* stopped – markp-fuso Dec 08 '22 at 23:41

0 Answers0