>So the first question is simply, is there an easier way, other than comparing all the other fields in the inserted table against the same fields in the same record in the deleted table? Further, is there any way to do it generically? IOW, without having to hard code the actual fields names into the trigger. If this simply involved one or two fields, it would be relatively easy.
>

Just a thought, and this depends on if the 'last update date' is comming in different or the same. One thought is to select distinct a union of INSERT and DELETED tables... if the rowcount is 1 then there are no changes, if the rowcount is 2 then there are changes. This assumes the lastupdate field is not changed in the update, and the trigger is responsible for putting that value in there.

If the last date does come in changed, you may be able to create a temp table with the last date changed back to the original so it won't be considered, but this would have a performance hit, and may require less generic code.

To be more generic you can probably use the COLUMNS_UPDATED() function in the trigger. This returns a string of bits which indicate if the fields where changed. You could look at all the bits except the one for the datestamp to determine if any changed. Although, I am not sure if this will show changed even if the update statement sends the same value, it may just flag each column included in the UPDATE as 'changed'.

>The second question is, assuming that there isn’t another way, can anyone give me any idea of the degree of severity this will impact performance? The tables are relatively small (1000-2000 records), with about an average of 20 fields to be compared.
>

It should be minimal... espesially if you write pretty straingforward code... Also, are you expeciting batch updates or is it sending one update at at time?

Where you planning on ROLLING BACK the update if it isn't really an update, or just setting the datechanged back to the orig value?


BOb