I am a dba and have gotten into a difference of opinion with the 'Middle tier' developers and so want to know what others are doing:
I have been writing Sql code for a long time. For standard updates what I have been doing is: Written sprocs in a way where there is a 'select' sproc which sends all the fields in the row from a table to the 'GUI' or 'Middle tier' along with the timestamp for the row. The front-end makes changes to some of the fields and makes an update in a way that they call an update sproc which expects all the fields, regardless of whether they were updated or not. Makes the update if the timestamp sent back at the time of the update matches the selected timestamp.
Now some of the Middle tier developers want to pass in just the fields that have changed when calling the Update sproc. This would mean that inside the sproc I'll have to determine which fields they are sending in and then either dynamically build a Sql string for Update or else inside the sproc default the input parameter values to NULL, look for not null fields and do an 'Update'.
If you go the 'NULL' route another problem is that what if the caller of the 'Update sproc' actually wanted to send a value of 'NULL' as the updated value of the field. Then we get into creating our own kludgy protocols to get around this problem.
I want to enforce 'select all fields from a table and make whatever changes you want, but send all the fields back along with the timestamp' at the time of update. Reduce extra work for Sql Server, so it does not become a bottleneck when thousands of rows are being inserted and updated all the time.
What do you say? and is this not really a standard way everyone is doing it.