在服务器数据库发生任何变化时更新客户端
我在 VS + SQL Server 2008 上制作了一个程序，并在通过 LAN 连接的 3 台计算机的家庭网络上启动它，该程序从数据库中获取数据并将其放入数据集中，因此用户将处理数据集和任何更新、删除或添加数据集上的内容将更新数据库。 数据库位于其中一台 PC（服务器）上，该 PC 也运行相同的应用程序，其他两台 PC 只是客户端，并从服务器数据库中获取数据。
我的问题是，当一台电脑更新数据库时，其他电脑不知道该更新，因此，例如，如果一个用户删除一个项目，而另一个用户删除同一项目..这将导致错误。
我的问题很明显：如何通过数据库中的任何更改来更新所有 PC？
最后一件事每个应用程序仅与服务器上的 SQL Server 数据库通信，而不与其他 PC 上的其他应用程序通信。
I made a program on VS + SQL Server 2008 and launched it on a home network of 3 computers connected through LAN ,The Program fetches data from database and Put it in Dataset ,So users will work on the datasets and any Update ,delete or add on the dataset will update the Database.
The database is on one of the PC (server) which is also running same app,other two PCs are just clients and take there data from the Server database.
My problem is when one PC update the database the other PCs do not know of that update,So for example if one user delete an item and the other user delete the same item ..It will cause an error.
My Question is obvious : How Can I make all PCs updated by any change in Database ?
One Last thing each App talks only with SQL server database on the server and does not talk with other Apps on other PCs.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是一个常见问题，并且通常通过乐观并发检查来处理（现在） - 基本上，让用户尝试删除/更新，但当行过期时失败。
乐观并发的基本模式是每行都有
rowversion列。在执行 UPDATE 之前，您将内存中的rowversion与服务器rowversion进行比较。如果它们不匹配，那么您就知道其他人已经更新了该行并且需要重新加载。对于DELETE，我个人会默默地使DELETE失败 - 毕竟，如果用户想要删除一行，那么它是否事先被删除真的很重要吗？另一种模式是悲观的，它基本上在任何用户正在处理该行时锁定该行。这具有服务器资源、用户离开机器等明显的缺点，但可以使用 SQL Server 锁定（例如，
FOR UPDATE、事务）或应用程序级锁定（例如，SQL Server 锁定）来实现。 ，检查共享数据库表）。使用 MS SQL Server，您还有另一种简单的选择 -
SqlDependency。这允许 SQL Server 在查询结果发生更改时通知您（通过事件处理程序），此时您可以重新加载数据。正如您可以想象的那样，这需要一些服务器资源 - 但由于您只有三个客户端而没有中间层，所以它应该是理想的。This is a common problem, and is generally handled (these days) by optimistic concurrency checking - basically, letting the user try to delete/update but then failing when the row is out of date.
The basic pattern for optimistic concurrency would be to have
rowversioncolumn with each row. Before doing an UPDATE, you compare the in-memoryrowversionto the serverrowversion. If they're mismatched, then you know somebody else has updated the row and it needs to be reloaded. ForDELETE, I would personally just silently fail theDELETE- after all, if a user wants to delete a row, does it really matter if it was deleted beforehand?Another pattern is pessimistic, which basically locks the row while any user is working on it. This has the obvious downsides of server resources, users walking away from the machine, etc. but can be implemented using either SQL Server locking (eg.,
FOR UPDATE, transactions) or application level locking (eg., checking a shared database table).With MS SQL Server, you do have one other easy option -
SqlDependency. This allows SQL Server to notify you (via an event handler) when the results of a query has changed - at which point you can reload the data. As you can imagine, this takes some server resources - but since you only have three clients without a middle tier, it should be ideal.