Provide properties to help with common tasks in CLR triggers - by Adam Machanic

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 265346 Comments
Status Closed Workarounds
Type Suggestion Repros 0
Opened 3/26/2007 11:42:21 AM
Access Restriction Public


As of today, I find CLR triggers to be next to useless, because they don't solve any problems that I can't solve just as easily, if not more so, in pure T-SQL triggers.  I would like to see properties added to the stack, available from CLR triggers, to help with common tasks.
Sign in to post a comment.
Posted by Microsoft on 12/19/2007 at 10:22 AM
Hi Adam,

I missed the proposed solution section earlier. Thanks for pointing that out. I do agree that we should add these properties and we will consider it in a future release.
Unfortunately this wouldnt make into SQL Server 2008.

-Vineet Rao.
Posted by Adam Machanic on 9/11/2007 at 12:32 PM
Hi Vineet,

Copying from the "Proposed Solution" section:

A) A table name property, that returns the name of the table that the operation affected rows in.

B) A rows affected property. Yes, I can set up a connection and query @@ROWCOUNT, but why should I have to do what the API can do for me?

C) A property that returns a collection with all of the column names updated (and even better would be other metadata, e.g. data type, precision, length, etc)

... and ...

D) Whether the operation was an insert, delete, or update

Posted by Microsoft on 8/20/2007 at 2:48 PM
Hi Adam,

Thanks for your feedback. Can you explain what all properties are you looking for to be available inside the trigger?

- Vineet Rao
Program Manager
SQL Server Engine.