Oh please...I've never violated anyting in my life and that index is LYING!!!

I had a DBA who would thump my nose everytime he found an SP with no error handling.


>I use TRY/CATCH to catch the error. And I named my error message variable/parameter ErrorMessage too ( I think you are violating my copyright <g>). So I suppose my approach is not a bad practice. Thank you.
>
>>IIRC, yes, every stored procedure that could generate an error should have an output parameter. Mine was always called ErrorMessage (or some such) and used to pass back the Error Message - which can be done, again iirc, through raiseerror?
>>
>>
>>>Hi,
>>>
>>>In my VFP stored procedures I always returned a string; empty if no problem occurred; or the string would have a description of the error, if a problem occurred.
>>>
>>>In SQL Server stored procedures, I learned today, I can only return an integer. I am thinking about returning 0 if no problem and -1 if there is a problem. Then, if there is a problem, set to an OUTPUT parameter the value of error message. I am wondering if this would be a good practice? My concern is that then each and every stored procedure would have to have an OUTPUT parameter.
>>>
>>>I would appreciate any suggestions on this topic. TIA.