MS SQL Server 2008检查约束和LINQ到SQL

这是一个棘手的问题...所以忍受着我。MS SQL Server 2008检查约束和LINQ到SQL

我在我的数据库中有两个表，[Item]和[AssignedProperty]。 [AssignedProperty]是与[Item]有亲子关系的孩子。所以它基本上只有一个ItemID字段和一个使用它的外键关系。 [AssignedProperty]也与另一个名为[Property]的表以及它自己的主键AssignedPropertyID具有相同的关系。这创造了一个很好的多对多关系。然而，我有一个限制，即规定一个[AssignedProperty]不能在同一条记录中出现ItemID和PropertyID的重复。因此[Item]只能有一个[Property]。

这很好用，但对于LINQ-to-SQL，我认为这是一个与我们的约束冲突的执行顺序问题。

为了产生此错误，我在我的应用程序中使用LINQ-To-SQL加载[Item]。然后我从项目的[AssignedProperties]集合中选择一个[AssignedProperty]]对象并将其删除。然后，我创建一个新的[AssignedProperty]对象，它具有与刚刚删除的ItemID和PropertyID完全相同的ItemID和PropertyID，并将其添加回集合中。当我在DataContext上调用[SubmitChanges]时，它会在约束上标记我。如果旧的[AssignedProperty]记录首先被删除，那么没有理由为什么新的记录会产生该错误。它看起来像是在删除旧的之前试图插入新的[AssignedProperty]。

我该如何解决这个问题，并在数据库或我的应用程序？ TIA

来源

2010-09-27 instantmusic

ItemID，PropertyID是您的AssignedProperty表中的主键吗？是的，你能解释为什么你删除并重新插入完全相同的记录？但修复很简单：只要提交更改两次，删除后和重新插入后 – Francisco 2010-09-27 17:27:54

啊，如果我不得不忘记的东西就是这样，哈哈。 AssignedProperty有它自己的主键，AssignedPropertyID，autoincrement。就项目而言，用户可以随意对项目实体进行多项更改，并随时保存或拒绝更改。因此，应用程序尝试处理这种情况的方式是，所有更改都可以同时提交。理想情况下，用户可能不会删除AssignedProperty并再次完全相同。但它可能。 – instantmusic 2010-09-27 17:37:36

我认为可以完成的唯一方法是，您的应用程序会检测AssignedProperty何时被删除然后重新插入，因此它不会首先将其删除。我不认为从数据库中删除约束是个好主意，因为数据迟早会被损坏。我不知道任何方式可以预测linq2sql处理所有事务的方式，或者强制执行命令，因此这也可能是一种非常困难的方法。 – Francisco 2010-09-27 20:19:36

94％的人在嘲笑我，而答案实际上是在原帖的评论中。

所以，这只是让我可以选择一个答案。

来源

2011-01-07 17:01:07 instantmusic

MS SQL Server 2008检查约束和LINQ到SQL

回答

相关问题