LINQ 无法识别数据库中的更改
我没有找到类似的东西，所以我不得不问：
我使用 LINQ to SQL，一切都很好，直到我开始使用存储过程来更新数据库条目。 （我的存储过程类似于更新 groupid x 的所有条目） 更新运行正常并且数据库中的值发生变化。但 DataContext 会忽略此更改。
我不得不说，数据上下文是单例，我知道这不是常见的方式，但我有不同的原因为什么我必须这样做。
所以
db.Refresh(System.Data.Linq.RefreshMode.OverwriteCurrentValues);
没有帮助。
为什么他不知道db的变化？
I did not find something similar so I have to ask:
I use LINQ to SQL and all was fine until i started to use Stored Procedures to update the database entries. (My Stored Proc is something like update all entries which groupid x)
The Update runs fine and the values in the database change. But the DataContext ignores this changes.
I have to say that the data context is a Singleton which I know is no common way but I have different reasons why I have to do it like this.
so
db.Refresh(System.Data.Linq.RefreshMode.OverwriteCurrentValues);
doesn't help.
Why he doesn't know the changes of the db?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您尝试做的事情非常违背 LinqToSql 的工作方式。
正确使用长期存在的 DataContext 非常困难，特别是当您需要调用存储过程时，LinqToSql 无法轻松跟踪数据更改。
通常会自动跟踪通过 DataContext 所做的更改，因此 DataContext 可以正确管理其缓存并跟踪该 DataContext 对数据库所做的更改。然而情况并非总是如此。 DataContext 不（也不容易）理解您的存储过程正在做什么，因此它不知道如何保持其缓存正确。此时，在调用存储过程后，最好的选择是删除该 DataContext 并创建一个新的 DataContext。这实际上会破坏您的缓存，这可能会或可能不会对性能造成重大影响，但数据完整性应该是您最关心的问题。
如果您的 Singleton DataContext 不是唯一修改数据库的东西（例如，您的数据库可能被触发器、批处理、其他应用程序等修改），那么您的 DataContext 的缓存中也可能包含不准确的数据，这会导致数据不准确。这是 DataContext 寿命短暂的另一个原因。
因此，虽然您可能会通过长期存在的 Singleton DataContext 取得成功，但您将全程与系统作战，并且系统最终很可能获胜。
您必须决定：数据完整性有多重要？
What you are trying to do goes very much against how LinqToSql works.
Using a long lived DataContext is very difficult to do correctly, especially if you need to call stored procedures, where LinqToSql can't easily track the data changes.
Changes you make through the DataContext are generally tracked automatically, so the DataContext can properly manage its cache and keep track of changes being made to the database from that DataContext. That isn't always the case however. The DataContext doesn't (and can't easily) understand what your stored procedure is doing, so it has no idea how to keep its cache correct. At that point, after calling the stored procedure, your very best option is to get rid of that DataContext and create a new one. That effectively blows away your cache, which may or may not be a significant performance hit, but data integrity should be your primary concern.
If your Singleton DataContext isn't the only thing modifying the database (for example, your database could be modified by things like: triggers, batch processing, other applications, etc.), your DataContext may also contain inaccurate data in its cache, which is yet another reason to have a short lived DataContext.
So, while you could possibly succeed with a long lived Singleton DataContext, you will be fighting the system the entire way and the system is likely to win in the end.
You have to decide: How important is data integrity?
因为数据上下文正在缓存值。这是一篇关于如何清除缓存。但现在你遇到了实施一个知道何时清除它的通知系统的问题。
Microsoft 建议数据上下文仅用于单个工作单元。将其作为单一实例
可能并不是一个好主意。Because the datacontext is caching the values. Here's an article on how to clear the cache. But now you have the problem of implementing a notification system of knowing when to clear it.
Microsoft recommend that a data context should be only used for a single unit of work. Hanging onto it as a singleton
probablyisn't a good idea.