主键身份值因唯一键约束违规而增加

发布于 2024-08-27 00:18:01 字数 522 浏览 8 评论 0原文

我有一个 SqlServer 2008 表,其中有一个主键 (IsIdentity=Yes) 和构成唯一键约束的其他三个字段。

此外,我有一个存储过程,用于将记录插入表中,并使用 SqlConnection 对象通过 C# 调用存储过程。

C# sproc 调用工作正常,但是当 C# sproc 调用违反唯一键约束时,我注意到有趣的结果......

当 sproc 调用违反唯一键约束时,会抛出 SqlException - 这并不奇怪,也很酷。但是,我注意到成功添加到表中的下一条记录的 PK 值并不比前一条记录多 1 -

例如:假设表有 5 个记录,其中 PK 值为 1,2,3, 4 和 5。存储过程尝试插入第六条记录,但违反了唯一键约束,因此未插入第六条记录。然后存储过程尝试插入另一条记录,这次成功了。 - 这条新记录的 PK 值为 7,而不是 6。

这是正常行为吗?如果是这样,你能给我一个理由吗? (如果记录插入失败,为什么 PK 索引会增加?)

如果这不是正常行为,您能给我一些关于为什么我会看到这些症状的提示吗?

I have a SqlServer 2008 table which has a Primary Key (IsIdentity=Yes) and three other fields that make up a Unique Key constraint.

In addition I have a store procedure that inserts a record into the table and I call the sproc via C# using a SqlConnection object.

The C# sproc call works fine, however I have noticed interesting results when the C# sproc call violates the Unique Key constraint....

When the sproc call violates the Unique Key constraint, a SqlException is thrown - which is no surprise and cool. However, I notice that the next record that is successfully added to the table has a PK value that is not exactly one more than the previous record -

For example: Say the table has five records where the PK values are 1,2,3,4, and 5. The sproc attempts to insert a sixth record, but the Unique Key constraint is violated and, so, the sixth record is not inserted. Then the sproc attempts to insert another record and this time it is successful. - This new record is given a PK value of 7 instead of 6.

Is this normal behavior? If so, can you give me a reason why this is so? (If a record fails to insert, why is the PK index incremented?)

If this is not normal behavior, can you give me any hints as to why I am seeing these symptoms?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

爱你不解释 2024-09-03 00:18:01

是的,这是正常的。

想象一下这里发生的事务,这是 SQL Server 上运行的潜在操作顺序。

  1. 使用 ID 1、2、3、4、5。
  2. 客户A开始交易。
  3. 客户端 A 执行插入但不提交(ID 6)。
  4. 客户端B开始交易。
  5. 客户端B执行插入但不提交。 (ID 7)。
  6. 客户端A回滚。
  7. 客户端 B 提交。

由于这种行为的可能性(不一定存在),您会看到当插入失败时 ID 6 被跳过。

Yes, this is normal.

Imagine transactions going on here and this being a potential order of operations ran on SQL Server.

  1. IDs 1, 2, 3, 4, 5 are used.
  2. Client A begins transaction.
  3. Client A performs insert but does not commit (ID 6).
  4. Client B begins transaction.
  5. Client B performs insert but does not commit. (ID 7).
  6. Client A rolls back.
  7. Client B commits.

Because of the possibility for (not necessarily existence of) this behavior, you see that ID 6 gets skipped when that insert fails.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文