December 25, 2013 at 9:40 pm
Comments posted to this topic are about the item predict the output
Every rule in a world of bits and bytes, can be bend or eventually be broken
MyBlog About Common dialog control
A Visualizer for viewing SqlCommand object script [/url]
December 25, 2013 at 9:48 pm
This was removed by the editor as SPAM
December 25, 2013 at 11:09 pm
Thanks for the question Thava ๐
_______________________________________________________________
To get quick answer follow this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
December 26, 2013 at 2:24 am
Nice question Thava.. Thanks!
~ Lokesh Vij
Link to my Blog Post --> www.SQLPathy.com[/url]
Follow me @Twitter
December 26, 2013 at 3:00 am
easy one for the day ๐
December 26, 2013 at 6:47 am
Thanks to Thava for the question. It usually makes a good question to point out those areas in SQL Server where the actual behavior doesn't match the expected behavior.
(Edited to insert word "Server".)
[font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
Connect to me on LinkedIn
December 26, 2013 at 6:54 am
I remembered the double behaviour!
๐
December 26, 2013 at 7:08 am
Good question!
This little idiosyncrasy drove me nuts when I first ran into it.
December 26, 2013 at 7:28 am
i agree with thomas
well in our concern we have faced a serious issue on this one that's why i posted it here, in our concern we usually deploy the empty backup to the customer and there we run a default procedure to populate the mandatory table detail, the same procedure also used for year end updation it deletes all the existing records and reset all the identity to 1, all goes well until that day
one of our client ask us to prepare the script for the database and ask to deploy it in his server, Every thing goes well, what make us stumped was this DBCC CHECKIDENT, when the user wants the default data, we run that procedure ,we usually start identity with 1, but there it start's with 0 and the night mare begins, then i do a little Google search but no help, well then i decide to read detail in msdn finally i found it and know why it happen, then we change the entire procedure with some little tweaks and also update the clients system (Tedious but a fatal error is gone)
Every rule in a world of bits and bytes, can be bend or eventually be broken
MyBlog About Common dialog control
A Visualizer for viewing SqlCommand object script [/url]
December 26, 2013 at 9:54 am
Easy but very nice. Thanks, Thava!
December 26, 2013 at 11:59 am
Good question, but the explanation should really mention that DBCC CHECKIDENT has two different behaviors based on whether or not there have been prior (non-truncated) rows present. I know that the link explains it all, but the given explanation basically comes down to "Read Books Online," which applies to every question. A good explanation should at least summarize the objective of the question. Thanks for the question though!
December 26, 2013 at 5:48 pm
thank you!!
I didn't know the RESEED's double action.
only when after creation or truncating table, new_reseed_value is used. I got it!
December 28, 2013 at 1:01 am
NBSteve (12/26/2013)
Good question, but the explanation should really mention that DBCC CHECKIDENT has two different behaviors based on whether or not there have been prior (non-truncated) rows present. I know that the link explains it all, but the given explanation basically comes down to "Read Books Online," which applies to every question. A good explanation should at least summarize the objective of the question. Thanks for the question though!
Agree +1
Thanks & Best Regards,
Hany Helmy
SQL Server Database Consultant
December 29, 2013 at 8:26 pm
Good question.
The delete in the second case almost made me get it wrong, because deleting all the rows doesn't have the same effect as truncating the table of never inserting any rows; but it felt wrong, and I stared it until I realised that that delete wasn't deleting anythig, because no rows had ever been inserted, so the new value wouldnt be incremented to get the identity on first use.
I always wonder why SQL Server behaves this way, though; it seems pretty bizarre, and doesn't seem useful.
Tom
December 30, 2013 at 11:46 am
L' Eomot Inversรฉ (12/29/2013)
I always wonder why SQL Server behaves this way, though; it seems pretty bizarre, and doesn't seem useful.
My guess - one day, someone discovered that the way the code for IDENTITY was written happened to cause this behaviour. And then they decided not to fix it, but to describe it. Probable reasons for this decision:
1. Maybe the IDENTITY code is not nice modularized, but spread out throughout the other code, and changing it is hard and risky. Too hard and risky.
2. Maybe MS realized that the intended use of IDENTITY is to generate numbers, and hence decided not to put any effort in influencing which numbers are generated.
3. Maybe MS found out that, despite what I just wrote above, some important customer actually has code that relies on this behaviour, and they didn't want to tick off this customer by changing it.
It's probably a combination of at least two of the above.
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply