General information
Forum:
Microsoft SQL Server
>>>>Depending on the severity of the error, SQL Server may continue executing the trigger, or it may fail the trigger/rollback all transactions on the connection and raise the error immediately. In other words, there is no true error trapping in T-SQL.
>>>>
>>>>It looks like you are using @@Error as a secondary test of the return value of the nested SP calls. It's much better - and faster - to test as much as you can using IF..ELSE and SELECTs rather than depending on @@ERROR. For instance, in the mm_newid procedure you could return a NULL if there is a problem generating the ID.
>>>
>>>A NULL cannot be returned by stored procedure as return value. In case if such attemt is made, the error message "The 'xxxxxxx' procedure attempted to return a status of NULL, which is not allowed. A status of 0 will be returned instead" is generated and 0 is returned.
>>
>>User-defined functions take zero or more input parameters, and return a single value. Some user-defined functions return a single, scalar data value, such as an int, char, or decimal value.
>
>How is it related to the stored procedures we've been discussing?
Because Charles is using the return value of the procedure instead of an output parameter, I was thinking function call when I responded. I should have written that the mm_newid procedure can return a value outside of the key's domain if there is a problem generating the ID instead of returning NULL.
However, responding with a copy-and-paste from BOL seemed like a more appropriate response to your copy-and-paste. I'm not too good at having a dialog with a book. :)
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only