Does anyone have an opinion on using CONTEXT_INFO as an efficient way to "pass" application information to auditing triggers? Once could update the CONTEXT_INFO for the current connection string before doing any SAVE() to a table that required auditing. This would allow your triggers to include data from your application that is not necessarily in the table you are updating, RBS username for example (I cannot just use the SQL username). I need to include several fields in each audit record, the data will never be contained in the table being audited. CONTEXT_INFO accepts 128 bytes of binary data (fast so far in testing). I was theorizing to pass a string of the values, delimited in some way that I could parse via the TSQL trigger code. One stop to set my "custom" audit fields whenever they change before a save or transaction on the BO gets committed?

Thoughts? or suggestions on what you may have done to pass data to your audit triggers?

Keith Chisarik