|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Tuesday, May 21, 2013 3:51 PM
Points: 2,
Visits: 25
|
|
I am afraid that these two lines of code don't work when we delete some rows between Fld1=1 and Fld=10 instead of the last few rows as the example in the article.
Let's try below scripts: ...... //delete these three rows Fld1 3,4,5 delete from TestReseed where Fld1 between 3 and 5
//execute those two lines of DBCC code dbcc checkident("TestReseed", reseed,1) dbcc checkident("TestReseed", reseed)
//insert three rows back insert into TestReseed(Fld2) values (3) insert into TestReseed(Fld2) values (4) insert into TestReseed(Fld2) values (5) ....
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Today @ 6:52 AM
Points: 2,018,
Visits: 2,852
|
|
Verena_Techie_59 (12/3/2012) There are several reasons for congiguous identity keys.
1) It's much simpler to keep ID keys in sync between production and testing systems.
2) Coding can be simpler and more reliable. In testing I can add the rows, then delete where ID > (the max key before additions) then reset the ID key again. This is probably the best reason. When I am adding rows to a table. Of course no one else better be adding rows at the same time or it won't work anyway and I'll have to code to find the records I just added and then select the max key to reset back to.
3) It's clean.
4) What if your id keys don't go up by 1? You could run out of ID keys fast, having very large gaps and an application may not be able to handle keys that are larger than x.
5) Some designs depend on certain values for identity fields, probably a poor design mind you....
6) Some gaps are better left. Especially when cleaning up some data that has been live. There may be history attached to it that will be kept. I don't like to reuse keys in case someone coded against the ID's and some programmers have....
FYI: to do this for Sybase:
Select max(id) key from table (either before inserts or after deletions) and then use sp_chgattribute to reset the identity key back.
select max(table1_id) from database..table1 -- example 300
use database1 sp_chgattribute table1, 'identity_burn_max', 0, '300'
7) Reason 7 is for us OCD types!
OK. Thanks. I appreciate your answer.
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Today @ 6:52 AM
Points: 2,018,
Visits: 2,852
|
|
Brandon Forest (12/3/2012)
@ those who question why to do this. It's very simple, if you don't see the need to do it, don't do it. Questioning why someone else chooses to do something is their business not yours. If you don't agree or approve, simply shake your head and say "Bullshit" and move on. No one is interested in hearing you complain. Focus on the technique, not the why. Wrapping it in a transaction is a good idea. Why we do it is our business. 
Who is complaining? I asked why because I truly wanted to know. I never thought to be concerned with gaps.
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Today @ 9:44 AM
Points: 65,
Visits: 91
|
|
I've had to deal with a 32bit identity value that starts at 1, design and business changes mean that the expected range of a few million is now several billion...and within a few years, 2^32 is exceeded. Reseed at minvalue of 32-bit int, and you still have 2 billion values ... which becomes a problem in a year because growth is exponential.
There is a use case for this - sometimes it's a bandaid approach to stave off disaster (i.e. you start with a few thousand customers and sales go crazy, suddenly you have a million customers - extended downtime is not an option). Sometimes it's just a case of data changes - remember the golden rule of SQL: "It depends." Nobody runs their database the same as the next guy, so a few of you should be careful not to say this is never an option. Sometimes it is, but there's often a tradeoff. I can tell you from experience that if because of growth you have to reseed twice or three times - you really want a solid plan to permanently fix it. I've had to clean up the fallout from others' quick fixes.
|
|
|
|
|
SSC Journeyman
      
Group: General Forum Members
Last Login: Today @ 4:28 AM
Points: 88,
Visits: 244
|
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: Wednesday, May 08, 2013 10:24 AM
Points: 237,
Visits: 413
|
|
Brandon Forest (12/3/2012)
@ those who question why to do this. It's very simple, if you don't see the need to do it, don't do it. Questioning why someone else chooses to do something is their business not yours. If you don't agree or approve, simply shake your head and say "Bullshit" and move on. No one is interested in hearing you complain. Focus on the technique, not the why. Wrapping it in a transaction is a good idea. Why we do it is our business. 
Fine. BUT if you are going to show something that is quite out of the ordinary, disclaimers should be used. Complete code should be used and a full explanation of why someone might do something would be great.
There are several levels of readers here, and giving them half a story, with something that has so many pitfalls is fraught with danger. Those that have more complete grasp on the ramifications get it, but not everyone does and its a disservice to those that dont.
|
|
|
|