Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
elwoos
Master Smack Fu Yak Hacker
2052 Posts |
 Posted - 2005-05-20 : 12:01:23
|
| What is the best way to return an error value to an app. and why?I was considering having an output parameter in my sproc which returned an error value or 0 if no error but I'm now wondering if I should use Raiserror instead. Any suggestions?thankssteveA sarcasm detector, what a great idea. |
|
|
AjarnMark
SQL Slashing Gunting Master
3246 Posts |
Posted - 2005-05-20 : 12:21:25
|
| Why not use a RETURN value? I thought that was what they were made for.---------------------------EmeraldCityDomains.com |
 |
|
|
mpetanovitch
Yak Posting Veteran
52 Posts |
Posted - 2005-05-20 : 19:47:03
|
| I wouldn't recommend using RETURN, many of the values are reserved by SQL server and used internally. Which to use depends on what you want to accomplish. Using an OUT parameter I think is good practice in all DML procedures because if this procedure is ever called from another you can examine the error out from the calling procedure. In your application code you need to examine the parameter and that is fine. However if you want to force the application to handle the error you can use RAISERROR, this will also allow you to control the error message. This is good to ensure that a unhandled exception is handled. I've used both but ususally developers will but the procedure call in a try catch block to capture any errors.Mike Petanovitch |
|
|
|
TG
Master Smack Fu Yak Hacker
6065 Posts |
Posted - 2005-05-20 : 22:18:13
|
>>I wouldn't recommend using RETURN, many of the values are reserved by SQL server and used internally.I don't believe there are any restrictions on return values. Any integer will do and will not interfere with SqlServer.I think that for procedures that are called directly from applications, RAISERROR should be used (to return errors). You want something that will trigger error handling routines rather than counting on the application to examine return codes. Return codes are very usefull for "returning" status, success indicators, error reasons, etc to calling procedures and are not mutually exclusive to output parameters and raiserrors. from BOLquote:
The RETURN statement unconditionally terminates a query, stored procedure, or batch. None of the statements in a stored procedure or batch following the RETURN statement are executed.When used in a stored procedure, the RETURN statement can specify an integer value to return to the calling application, batch, or procedure. If no value is specified on RETURN, a stored procedure returns the value 0.Most stored procedures follow the convention of using the return code to indicate the success or failure of the stored procedure.
Be One with the OptimizerTG |
|
|
|
|
|
|
|
|
erroneous