对于 SharePoint 列表上缺少事务（回滚和提交）支持的解决方法是什么？
SharePoint 不提供对列表数据操作的事务（回滚和提交）支持。实现事务行为的解决方法是什么。
用例 1： 当在列表中添加一个项目时，我想更新另一个列表项目。但如果更新失败，我想回滚添加到第一个列表中的项目。
用例 2： 以编程方式更新 10 个列表项。如果第 10 次更新失败，我想回滚之前的 9 次更新。
尽管 SharePoint 列表不是关系数据库，也不应该作为关系数据库，但开发人员越来越多地使用它来存储业务关键数据（需要数据完整性），并且不鼓励使用外部列表，因为它对可用功能造成了很多限制在正常列表上。
SharePoint does not provide transaction (rollback and commit) support on List data operations. What are the workarounds to achieve transactional behavior.
Use case 1:
When an item is added in a List I want to update another List item. But if the update fails I want to rollback the item added to the first list.
Use case 2:
Updating 10 List items programatically. If 10th update fails, I want to rollback previous 9 updates.
Although SharePoint List are not relational database and should not be as a relational database, developers are increasingly using it for storing business critical data (which needs data integrity) and they are discouraged to use External List because it poses lots of restrictions on the features available on normal Lists.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
由于 SPList 不提供对事务的固有支持，因此您必须自己处理回滚操作。
在用例 1 和 2 中，模拟事务的最简单方法是在执行更新之前读取要更改的任何列表项的状态，然后在检测到故障时写回该状态。这不是一个完美的解决方案，因为足够严重的错误也可能会阻止您的回滚更新。这就是您因数据存储不支持事务而付出的代价。
话虽这么说，虽然许多客户确实会要求将业务关键数据存储在 SPList 中，但我认为您的工作就是让他们相信这不是一个好主意，并且通过 Web 服务访问的事务数据库是更安全的 SP兼容的方式来存储重要数据。
Since SPLists don't provide inherent support for transactions, you have to handle rollback operations yourself.
In both use cases 1 and 2, the easiest way to simulate a transaction is to read in the state of any list item you are changing prior to executing an update, and then write that state back should you detect a failure. It's not a perfect solution, since a sufficiently severe error might prevent your rollback updates as well. That's the price you pay for not having the data store support transactions.
That being said, while it's true many clients will ask for business critical data to be stored in SPLists, I would argue that it's your job to convince them that it's not a good idea, and that transactional databases accessed over webservices are a much safer SP compatible way to store important data.
我发现如果您使用支持版本控制的列表会更简单一些。
我使用中间类来访问列表项。当我在该类上调用 .Update() 时，我会存储正在更新的任何项目的当前版本 ID。如果稍后在“事务”中出现任何问题，我只需恢复到该版本 ID 即可。
I find it's a little simpler if you use lists that support versioning.
I use a intermediary class to access list items. When I call .Update() on that class, I store the current version id of any item that I am updating. If anything goes wrong later in the "transaction" I simply revert back to that version id.