您如何知道下一个身份栏会是什么?
是否有一个 tsql 查询来告诉它期望用于下一行插入的 SQL Server 标识列值?
编辑添加:
我删除并重新创建了一个表,
[personID] [int] IDENTITY(1,1) NOT NULL
作为 CREATE TABLE 命令的一部分。 我还尝试重新播种标识列,同时删除该表中的所有信息,但这并不总是有效。 这让我想知道是否有办法查看 SQL 期望对下一个标识列号使用什么。
Is there a tsql query to tell what SQL server identity column value it expects to use for the next row insert?
Edited to add:
I deleted and recreated a table with
[personID] [int] IDENTITY(1,1) NOT NULL
as part of my CREATE TABLE command. I've also attempted to reseed identity columns while removing all information in that table and that hasn't always worked. It got me to wondering if there was a way to see what SQL expected to use for your next identity column number.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
您可能希望使用 SCOPE_IDENTITY 而不是 @@IDENTITY 将其限制为当前范围内的标识值。 这可以避免触发器将新的标识值插入到其他表中,而不是插入到刚刚插入的表中。
但您可以计算下一个身份值是什么。
问题是您不能保证这就是该值。
您必须拥有一个锁,以便在运行表时拒绝表上的其他插入,以确保该值准确。 另外,当你用完 32 位整数后,我不知道逻辑是什么。 不知道是翻车了还是失败了。
编辑:
我刚刚对此进行了测试(请参阅下面的 SQL),当没有数据时它不会返回正确的值。
使用 DBCC CHECKIDENT ('tablename', RESEED, 200) 重新播种实际上导致下一个值是 201 而不是 200。
You probably want to use SCOPE_IDENTITY not @@IDENTITY to restrict it to the identity value in the current scope. This avoids getting new identity values inserted by triggers into other tables and not the table you just inserted into.
But you can calculate what the next identity value is
The problem is you aren't guaranteed that is the value.
You'd have to have a lock such that other inserts are denied on the table when running it to ensure the value is accurate. Also after you run out of 32 bit integers I don't know what the logic is. I don't know whether it rolls over or fails.
Edit:
I just tested this (see below for SQL) and it doesn't return the correct value when there is no data.
And reseeding with DBCC CHECKIDENT ('tablename', RESEED, 200) actually resulted in the next value being 201 not 200.
不,没有任何保证的方法(尽管您当然可以找出下一个值可能是什么,但在您可以使用它之前,另一个命令可能会使用它的)。 您可以检索的唯一有保证的值是之前通过
SCOPE_IDENTITY()
(这将返回当前作用域最后生成的标识值)。值得怀疑的是,为什么人们之前需要知道该值(当使用自动递增的种子标识列时)。
如果您之前需要知道该值,那么我建议您自己生成 ids。 您可以使用以表名称为键的 ids 表来执行此操作,或者,如果您有可伸缩性问题(并且您正在使用事务),您可以为每个需要 id 的表创建一个 id 表,该表将插入该 id (并随后递增)。
或者,您可以使用 GUID,并且可以在将其发送到数据库之前在客户端轻松生成这些 GUID。
No, there isn't any guaranteed way (although you can certainly find out what the next value might be, another command might go and use it before you can make any use of it). The only guaranteed value you can retrieve is the previously inserted identity value through
SCOPE_IDENTITY()
(which will return the identity value last generated for the current scope).It's questionable what purpose why one would need to know the value before (when using an automatically incremented seeded identity column).
If you need to know the value before, then I recommend generating the ids yourself. You can do this with an ids table keyed on the table name, or, if you have scalability concerns (and you are using transactions) you can have an id table for each table that needs an id which would have the id to be inserted (and subsequently incremented).
Or, you could use a GUID, and you would be able to easily generate these on the client side before sending it to your database.
这段 sql 将为您提供下一个标识列值(可能有很多原因不在生产代码中重复此代码段)
此 stackoverflow 问题提供了一些额外信息 - sql-identity-autonumber-is-incremented-even-with-a-transaction-rollback
This piece of sql will give you the next identity column value (there are probably many reasons not to repeat this snippet in production code)
this stackoverflow question gives some extra information - sql-identity-autonumber-is-incremented-even-with-a-transaction-rollback
由于您从 1 开始并递增 1 (IDENTITY(1,1)),我想知道您是否可以创建一个过程,在其中可以设置一个变量,如“Select @@IDENTITY + 1”或类似的内容。
Since you seed from 1 and increment by 1 (IDENTITY(1,1)), I'm wondering if you can create a procedure where you can set a variable like "Select @@IDENTITY + 1" or something like that.
使用
GUID
列作为主键。 除非您有数十亿条记录和每秒数千个请求,否则您可能不会注意到性能差异。 但除非你喜欢花太多时间处理这样的愚蠢问题,否则你会注意到压力水平和预期寿命的差异。Use
GUID
columns for your primary keys. Unless you have billions of records and thousands of requests per second, you probably won't notice the performance difference. But unless you like spending far too much time dealing with stupid issues like this, you will notice the difference in your stress level and life expectancy.