Do the CRM 4.0 Web Services force update of all entity fields even if they haven't changed

I have an application that i run daily to send contract updates to CRM from an external source. The process that I use is:

1. Download all existing entities from CRM via a SQL query.
2. Create an appropriate CRM entity object with all of the values populated
3. Find the appropriate entry in the external source and update the cha开发者_如何转开发nged fields
4. If any of the fields were flagged as being changed, then update the entity back to CRM.

My question is: are all of the fields updated in CRM, even though the value hasn't changed? or is CRM intelligent enough to only update fields with different values?

Thanks

Behind the scenes, I believe Microsoft CRM is using a SQL update for all of the attributes from the property bag that are not null. You can also turn on options to overwrite nulls.

This sounds like a typical delta process. I will give advice on what I believe are the two best ways to go about it that I've seen with Microsoft CRM -

1. (Most efficient) If you can hook up some triggers/plugins to the external source to propagate changes in realtime to a staging database that contains the change type (insert/update/delete), then have a nightly sync that processes the table (flagging affected records with a status) and pushes each row into CRM. After it finishes pushing the changes to CRM, it can delete all the delta rows from the staging database that have been flagged as processed.

2. (If realtime push is not available) If source system is the system of record for all the data you will need to read all values from Microsoft CRM (can do this directly or load them into a temporary database if you want to save load on CRM). As you do the reads, you should have an ID on the records to track them back to the source data. When you compare each value to the source database, write any differences to a staging table with the type of difference (insert/update/delete). Once you have built the delta staging database, process all those records into CRM in the same way as in part 1.