3

当我们可以捕获异常时： Violation of UNIQUE KEY constraint 'IX_Product'. Cannot insert duplicate key in object 'Product'. (2627).
挑战在于如何将索引名称 IX_Product 分解为成员（即我不想将消息子串化）。一个表上可能有多个唯一约束，我们需要知道哪一个可以向用户提供更详细的信息。最好将它作为 DbException 捕获，因此它不是特定于 SQL Server 的。有没有办法从异常中获取受影响的索引而不必解析字符串？

我想出但我没有测试过的唯一解决方案是使用存储过程并在其中捕获错误并从存储过程返回更详细的消息。但我相信这仍然会有问题。

4

5 回答 5

5

您必须：

  1. 编码您的客户端组件以识别每个插入/更新语句可能引发异常的约束名称，
  2. 重命名所有约束，以便它们以您希望在客户端代码中使用它们的方式“可破译”，或者......
  3. 在尝试插入/更新之前检查存储过程中的所有约束，如果检查失败，则在过程中抛出（引发）您自己的自定义异常，然后再尝试插入更新并让约束创建异常......
于 2008-12-29T16:26:17.827 回答
2

呃...也许我遗漏了一些明显的东西...但是不是更好地利用您的时间来修复错误而不是解析异常吗？

于 2008-12-29T16:19:18.903 回答
1

这听起来像是一个糟糕的设计问题。RDBMS应该强制执行这些事情，但应用程序也应该了解并围绕这些约束构建。期望您的 RBDMS 处理您的应用程序应该从一开始就捕获或阻止的逻辑异常是一件非常残酷的事情。数据库引擎用于数据操作，而不是用于向应用程序抛出异常。

于 2008-12-29T16:39:15.493 回答
0

一旦你把它作为一个异常对象解析是你最好的选择。不过，我不会太快将其视为一种实现而忽略它——带有组的正则表达式不应该太难完美适合您的情况。

您也可能最终在存储过程中得到类似的解决方案（解析）。此外，通过将解析代码推送到数据库服务器，您将强制您的数据库能够在不解析的情况下解析确切的细节（这在数据库 A 上可能微不足道，但在数据库 B 和 C 上却异常困难）。

于 2008-12-29T16:33:18.313 回答
0

不要解析异常文本。（在这里呼应安德鲁......）

如果您预计数据插入/更新操作中有许多可能的陷阱，您应该在 C# 层中捕获这些陷阱。从 ApplicationException 扩展以构建您自己的异常来处理这些特定的约束。

但这假设您的数据模型的位置使得您可以做出这些决定，而无需使用数据库告诉您可以成功执行语句。如果您的数据设计不允许您在不通过 db 引擎运行的情况下知道是否违反了约束，那么您的数据设计存在缺陷。

于 2008-12-29T16:55:56.987 回答