November 2, 2001 at 12:00 am
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sjones/identitylocking.asp
January 14, 2002 at 1:20 am
Hi,
Good work, b/c I have done something like storing IDENTITY values in a table in the good old days of FOXPro but Access, SQLServer and even other DBMS products support some kind of ID generation which I think is a better choice. Isn't there anything about the method SQLServer uses to get IDENTITY values?
January 14, 2002 at 5:31 am
Steve - have you tried comparing your test with one where the table doesn't have identity column? Or maybe uses unique identifier? I'd like to see those results!
Andy
January 17, 2002 at 4:43 pm
Hi,
I am probably missing something, but what was the result after all? Were the values spread across different sources or groupped together by the source. I don't think the article states this.
Thank you!
Michael
January 21, 2002 at 10:05 am
This was bascially a test because I was wondering if identity was better than storing the value in a table and manually updating it with each insert. It was a kind of benchmark to see how SQL handles the identity.
I would like to update this to use uniqueidentifer and run some timing benchmarks.
Steve Jones
January 21, 2002 at 4:03 pm
Under most circumstances I agree that an Identity column is a simple method for numbering rows.
On occasions where an insert is needed with the "Set Identity_Insert ON" function be aware that: [Execute permissions default to the sysadmin fixed server role, and the db_owner and db_ddladmin fixed database roles, and the object owner] from BOL.
i.e. a user may not be able to perform a bulk insert unless they have these permissions.
January 21, 2002 at 4:55 pm
January 21, 2002 at 4:58 pm
Viewing 8 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply