That sounds like a good strategy, monsieur_champs. I just wanted to warn you away from trying to optimize a few hundredths of a second off an update - if you were going to query the database to compare the columns so you could only update the ones that changed, that would almost certainly take more time than updating all of them. If you have valid reasons for not updating some columns, however, that's something else entirely. You could always "cache" the original values in the form and compare the cached values to the new ones - but it is unlikely to be worth the trouble.

MrChromeDome raises a good point about updating indexes and keys (with constraints) - although I would argue it probably wouldn't matter for a single update on a single table. However, in a good database design the index will generally not change when you update a record (changing the index would change its essential identity, which would be logically equivalent to deleting the record and inserting another). Also, if the column is not really changing (you are setting it to the original value), the database should be smart enough to recognize that. Another thing to take into account (when updating many rows on databases that support it) is the possibility that there is an update trigger on the table, which may do different things depending on the column updated. If you are updating millions of records, triggers, indexes, and constraints can make a big difference.