|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Friday, March 27, 2009 10:01 AM
Points: 48,
Visits: 123
|
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Friday, May 17, 2013 2:04 AM
Points: 1,968,
Visits: 1,819
|
|
Thanks! Some times sql behave in unexpected manner.
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 6:20 AM
Points: 1,538,
Visits: 799
|
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Thursday, April 23, 2009 9:32 AM
Points: 109,
Visits: 70
|
|
| Okay, I'm lost. If RESEED sets the value back to zero and this table was RESEEDed right before both queries, then why wouldn't both queries return zero?
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Friday, May 17, 2013 12:52 PM
Points: 2,548,
Visits: 17,348
|
|
The result depends on whether or not any rows have been inserted into the table since it was created. If there haven't (like in the first reseed), the next value inserted is the reseed value. If there have, then the next value inserted is the reseed + 1. Interestingly enough, this ignores the “increment” value of the identity column. If you TRUNCATE the table instead of deleting the rows, the table acts as if there have been no rows added and the reseed uses the reseed value again. It is odd behavior, but it is also documented in BOL.
Thanks, Chad
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Tuesday, May 14, 2013 4:39 PM
Points: 6,260,
Visits: 1,977
|
|
Am I looking at the same question you are ? There is no TRUNCATE TABLE anywhere in the code!

* Noel
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Tuesday, May 14, 2013 4:39 PM
Points: 6,260,
Visits: 1,977
|
|
Nevermind, I think I am in need of coffee ;)
* Noel
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Thursday, April 23, 2009 9:32 AM
Points: 109,
Visits: 70
|
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Friday, March 27, 2009 10:01 AM
Points: 48,
Visits: 123
|
|
I am glad to see so many people getting this right. And for 3 points!
It certainly does not operate according to how I expect things to work. I just wished I had posted something more challenging than a simple script.;)
Perhaps something like:
Given a table defined as
CREATE TABLE id_test (my_id INT IDENTITY(1,1) NOT NULL)
and
(select count(*) from given_table) = 0
Select the right action to take to ensure that the next row inserted is 1
a) DBCC CHECKIDENT(id_test, RESEED, 0) b) DBCC CHECKIDENT(id_test, RESEED, 1) c) it depends, a) OR b) depending on the circumstance.
Bonus question: If you select c, you are correct. Now how would you determine which reseed statement to perform?
I am really interested in the answer to the bonus question as I have not been able to crack this.
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: Sunday, August 19, 2012 6:40 PM
Points: 202,
Visits: 301
|
|
raymond lew (3/3/2009)
I am glad to see so many people getting this right. And for 3 points! It certainly does not operate according to how I expect things to work. I just wished I had posted something more challenging than a simple script.;) Perhaps something like: Given a table defined as
CREATE TABLE id_test (my_id INT IDENTITY(1,1) NOT NULL)
and
(select count(*) from given_table) = 0
Select the right action to take to ensure that the next row inserted is 1
a) DBCC CHECKIDENT(id_test, RESEED, 0) b) DBCC CHECKIDENT(id_test, RESEED, 1) c) it depends, a) OR b) depending on the circumstance.
Bonus question: If you select c, you are correct. Now how would you determine which reseed statement to perform? I am really interested in the answer to the bonus question as I have not been able to crack this.
The answer to the bonus question is to use DBCC CHECKIDENT without reseeding :)
CREATE TABLE id_test ( my_id INT IDENTITY(1,1) NOT NULL)
DBCC CHECKIDENT(id_test)
INSERT INTO id_test DEFAULT VALUES; DELETE FROM id_test
DBCC CHECKIDENT(id_test)
INSERT INTO id_test DEFAULT VALUES; DELETE FROM id_test
DROP TABLE id_test go
Returns
Checking identity information: current identity value 'NULL', current column value 'NULL'. DBCC execution completed. If DBCC printed error messages, contact your system administrator.
(1 row(s) affected)
(1 row(s) affected) Checking identity information: current identity value '1', current column value '1'. DBCC execution completed. If DBCC printed error messages, contact your system administrator.
(1 row(s) affected)
(1 row(s) affected)
If DBCC CHECKIDENT (NORESEED) reports NULL for the current identity value, use 1. Otherwise, if it reports 1, use 0.
CREATE TABLE id_test ( my_id INT IDENTITY(1,1) NOT NULL)
DBCC CHECKIDENT(id_test)
DBCC CHECKIDENT (id_test, RESEED, 1)--reseed to 1
INSERT INTO id_test DEFAULT VALUES; select my_id FROM id_test --select number 1 DELETE FROM id_test
DBCC CHECKIDENT(id_test)
DBCC CHECKIDENT (id_test, RESEED, 0)--reseed to 0 + 1
INSERT INTO id_test DEFAULT VALUES; select my_id FROM id_test --select number 2 DELETE FROM id_test
DROP TABLE id_test go
I'll leave you with the challenge of parsing the output from DBCC CHECKIDENT.
Of course, there is also a trivial answer:
TRUNCATE TABLE id_test -- reset table to a known state DBCC CHECKIDENT (id_test, RESEED, 1)
|
|
|
|