>>>>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. :)