>As I said before, I default every column parameter to null, so it's a matter of determining which columns were changed by the user and only passing those as parameters.
>
>As long as you don't need to pass a NULL.

I don't see this as a problem, John. IMHO, a NULL simply means that the user has not made a choice and entered anything for that particular field. Once it *has* been changed and saved to the database, then it's not ever going to be NULL again. Fields will then have a "default" value if they aren't NULL, so if a user decides to "delete" the data out of a particular field, it will be set to this default (which will then get sent to the backend). In a datetime field, if a user changes an existing date to no date at all, we default that to "1/1/1900" (which is never displayed to the user), which is pretty standard I think.

~~Bonnie




>
>If you implement change tracking by default, you can still add pessimistic over the top. Whereas people who don't use datasets at all will find it fearfully difficult to implement change tracking. At least you use datasets, but your standard technique can only offer change management for tables that don't need NULL values. Which means no datetime fields, for a start. ;-) You see? "Prepare for the worst, don't hope for the best". Implement change tracking by default. If customers never use it: so what, you're generating efficient updates and keeping transaction logs relevant. Where is the downside?