Very useful hint
Regards
Beside some missing spaces in the code, which is confusing, I miss information how the Output option returns its values to the devolper.
Very valuable information to me. Too bad that te conclusion is wrong! There really is a need to perform modifications wherever @@identity or scope_identity() is used because they are not reliable:
So, my conclusion would be that it really is nescessary to rewrite code whenever you need the newly assigned identity.
Regards,
Hans van Dam
Yes indeed. Very valuable feature. Performance can be greatly enhanced by this, where triggers may be replaced. Those wondering about the missing spaces...
In the first example block, SELECTSCOPE_IDENTITY() should be SELECT SCOPE_IDENTITY(). In the last example block where the delete statements are WHEREID = should be WHERE ID =
Jimi, that's not quite correct. Here's what it says in BOL:
output_table cannot:
You can use it on any table regardless of configuration, it's only the output table where you're landing the results that has restrictions.
The output clause is one of the really nice improvements in 2005. I've seen all too many instances where developers were essentially inserting an alternate primary key so that they could insert multiple rows at once and still get the keys back. If they had used scope_identity() they would have been forced to insert the records one at a time which is not great for performance.
Essentially the output clause exposes the logical inserted and deleted tables that were previously only visible within the trigger execution.
Andy,
is it possible you to do following changes in the article
SELECTSCOPE_IDENTITY() should be SELECT SCOPE_IDENTITY() in first example block.
In the last example block where the delete statements are WHEREID = should be WHERE ID