防止多个用户在 sharepoint 2010 中编辑同一列表项
我们开发了一个具有多个控件的自定义 Web 部件，并部署在 sharepoint 2010 站点上，该站点接受用户的输入，一旦用户单击提交按钮，所有值都将存储在 sharepoint 列表中，其中一列是超链接。当用户点击这个超链接时，通过查询字符串他将再次重定向到相同的表单。
我想知道如果用户点击了这个超链接来对该表单进行编辑，我们是否可以避免其他用户对该表单进行更改？
请分享您对此的想法。
We have developed a custom webpart with multiple controls and deployed on sharepoint 2010 site which accepts inputs from the user and once the user clicks on the submit button all the values are stored in the sharepoint list with one of the columns being a hyperlink. When the user clicks on this hyperlink , through the query string he will redirected to the same form again.
I would like to know if the user has clicked on this hyperlink to make editions to this form, can we avoid another user from making changes to this form?
Please share your thoughts on this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果我正确理解您的问题，如果有人已经在编辑列表项，您希望阻止其他用户编辑该列表项。这可以使用某种锁来完成，可能存储在列表本身中，但该策略存在两个重要缺陷：
考虑到第一个用户单击链接切换到编辑模式，我们锁定列表项。如果用户只是关闭浏览器而不进行任何进一步操作（或者他的网络出现故障，或者他的系统崩溃，或者他的计算机死机），则该项目将保持锁定，并且其他所有人 将被阻止编辑它，直到我们以某种方式释放它（通常是在超时后，或者通过在 Web 部件之外对其进行修改）。
我们的 Web 部件将强制执行该锁定，但没有其他代码会执行此操作，包括 SharePoint 本身（通过另一个 Web 部件或服务器端代码）和整个外部世界（通过客户端对象模型）。因此，任何给定的列表项在用户编辑时仍然容易发生更改，并且如果发生这种情况，
SPListItem.Update()仍然会引发异常。更好的策略是使用 SharePoint 自己的锁定机制，在第一个用户切换到编辑模式时签出该项目，当然，仅在该项目尚未签出时才启用链接。
但是，这并不能解决延迟锁定问题（如果用户关闭浏览器，我们何时重新签入该项目？）。此外，CheckOut() 是由 SPFile，而不是 SPListItem，这意味着您必须使用文档库才能受益从该功能。
总而言之，我认为没有一个真正用户友好的解决方案来解决您的问题：您要么让您的用户同时编辑同一项目并处理后果（只有一个人获胜），要么您不这样做t，你可能会留下陈旧的锁（每个人都会输）。
If I understand your question correctly, you want to prevent further users from editing a list item if someone is already editing it. That can be done using some kind of lock, possibly stored in the list itself, but that strategy suffers from two important flaws:
Consider that the first user clicks the link to switch to edit mode, and we lock the list item. If the user just closes his browser without proceeding any further (or his network fails, or his system crashes, or his computer dies), the item will remain locked, and everybody else will be prevented from editing it until we release it somehow (usually after some timeout, or by tinkering with it outside of the web part).
Our web part will enforce that lock, but no other code will do so, including SharePoint itself (through another web part or from server-side code) and the whole outside world (through the Client Object Model). So any given list item would still be susceptible to change while the user is editing it, and
SPListItem.Update()would still raise an exception if that happens.A better strategy would be to use SharePoint's own locking mechanism, by checking out the item when the first user switches to edit mode and, of course, enabling the link only if the item is not already checked out.
However, that does not solve the lingering lock problem (when do we check the item back in if the user closes his browser?). Also, CheckOut() is implemented by SPFile, not SPListItem, which means you have to use a document library to benefit from that feature.
All in all, I don't think there's an actually user-friendly solution to your problem: you either let your users edit the same item at the same time and deal with the consequences (only one of them wins), or you don't and you might leave stale locks around (everybody loses).
使用结帐和检查，然后建立一个工作流程来清除锁定时间超过设定时间段的锁...
Use the checkout and checking and then have a workflow which clears locks that are locked for more than a set time period...
您可以使用 SharePoint 中的签出/签入机制。
You can use check out/check in mechanism in SharePoint.