Not using the generated code. You could hook into a stored procedure, but that may involve extra work.
For "last updated" data, it is possible to hook into the DataContext
's change-set that is obtained during the SubmitChanges
method - so it is possible set properties (perhaps based on an interface) for the rows that are being submitted for UPDATE
.
I have a similar issue, where my audit triggers behave differently based on which columns are part of the UPDATE
statement (via UPDATE(ColumnName)
in the trigger), so in a similar question I needed to hack the data-context to always consider a specific column dirty. That may have some cross-over.
But no: I don't think you can disable the triggers completely.