Thanks,

Rebeccah

I just found your post and implemented it. The proc where I built it in runs fine, but your error-handling ALWAYS brings up an error:

“Meldung 50000, Ebene 15, Status 1, Prozedur dba_logError_sp, Zeile 152
Zeichenfolgen- oder Binärdaten würden abgeschnitten.”

which means something like
“Message 50000, flat 15, status 1, procedure dba_logError_sp, row 152
String or binary data would be truncated.

Then I just set the declaration of @returnError to 0 and there was no error at all. Which is not the purpose of an error-handling.
Where could I have done something wrong?

Best regards from Vienna/Austria!
Martin

This is quite a bit after your post but I ran across it. Nice post, good information. I was wondering if you could post or email an example of the contents of the dba_logError_sp stored procedure?

I have a good handle on catching errors in my procs but the logic that goes into logging them and what to do next is a little less clear. It seems most of this unclearness is from what this stored proc actually does.

Thanks.

The error proc, dba_logError_sp , will indeed return the error to the calling app if @returnError = 1, which is the default behavior.

/* Should we return an error message to the calling proc? */
IF @returnError = 1
RAISERROR
(
@errorReturnMessage
, @errorReturnSeverity
, 1
) WITH NOWAIT;

The reason I wrote the return section this way is that I’ve used the error logging proc as a form a of debug; if a condition occurs that I want to be logged but I don’t want to return an error, I set @returnError = 1 and @forceExit = 0.

To your point, you could modify the error proc to return -1 and have your application check for and handle errors based on the return value. This just depends on your application preferences.

-Jamie