CRM 4.0 Web 服务是否强制更新所有实体字段，即使它们没有更改
我有一个每天运行的应用程序，用于从外部源向 CRM 发送合同更新。我使用的流程是：
- 通过 SQL 查询从 CRM 下载所有现有实体。
- 使用填充的所有值创建适当的 CRM 实体对象
- 在外部源中查找适当的条目并更新更改的字段
- 如果任何字段被标记为正在更改，则将该实体更新回 CRM。
我的问题是：即使值没有改变，CRM 中的所有字段是否都已更新？或者 CRM 是否足够智能，只能更新具有不同值的字段？
谢谢
I have an application that i run daily to send contract updates to CRM from an external source. The process that I use is:
- Download all existing entities from CRM via a SQL query.
- Create an appropriate CRM entity object with all of the values populated
- Find the appropriate entry in the external source and update the changed fields
- 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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在幕后，我相信 Microsoft CRM 正在对属性包中所有不为空的属性使用 SQL 更新。您还可以打开选项来覆盖空值。
这听起来像是一个典型的德尔塔过程。我将就我认为在 Microsoft CRM 中见过的两种最佳方法提供建议 -
（最有效）如果您可以将一些触发器/插件连接到外部源以传播更改实时到包含更改类型（插入/更新/删除）的临时数据库，然后进行夜间同步来处理表（用状态标记受影响的记录）并将每一行推送到 CRM 中。将更改推送到 CRM 后，它可以从临时数据库中删除所有已标记为已处理的增量行。
（如果实时推送不可用）如果源系统是所有数据的记录系统，您将需要从 Microsoft CRM 读取所有值（可以直接执行此操作，或者如果您想保存，则将它们加载到临时数据库中）加载到 CRM 上）。当您进行读取时，记录上应该有一个 ID，以便将其追溯到源数据。将每个值与源数据库进行比较时，将任何差异写入临时表并指定差异类型（插入/更新/删除）。一旦您构建了增量临时数据库，请按照第 1 部分中相同的方式将所有这些记录处理到 CRM 中。
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 -
(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.
(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.