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.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham
