Current Framework 2.0/3.0.

...

In Sql Server, there is a way to generate consecutive guid's.
newsequentialid.

Is there a way to reproduce this type of consecutive guid's in the
framework.

I found some info about uuidgen , but that seems like a command line prompt
tool, not a class library.

I'd like to be able to throw an int value (N) at it, and it return N
consecutive guid's.


.........


Here is a test stored procedure I wrote to show you what I'm talking about.








IF EXISTS (SELECT * FROM sys.objects WHERE object_id =
OBJECT_ID(N'[dbo].[uspNewSequentialUUIDCreateRange]') AND type in (N'P',
N'PC'))

DROP PROCEDURE [dbo].[uspNewSequentialUUIDCreateRange]

GO



CREATE PROCEDURE [dbo].[uspNewSequentialUUIDCreateRange] (

@newUUIDCount int --return

)

AS

SET NOCOUNT ON

declare @t table ( dummyid int , entryid int identity(1,1) , uuid
uniqueidentifier default newsequentialid() )

insert into @t ( dummyid ) select top (@newUUIDCount) 0 from dbo.sysobjects
so with (nolock)

select entryid , uuid from @t

SET NOCOUNT OFF

GO









/*

--START TEST

set nocount ON

Create Table #HolderTable (entryid int , uuid uniqueidentifier )

declare @NewUUIDCount int

select @NewUUIDCount = 20

INSERT INTO #HolderTable EXEC dbo.uspNewSequentialUUIDCreateRange
@NewUUIDCount



select * from #HolderTable



DROP Table #HolderTable

--END TEST CODE



*/

System.Guid.NewGuid()

--
John Saunders | MVP - Connected System Developer

I don't see a way to do this with the System.Guid class. newsequentialid was
introduced to provide some optimization in SQL, but that was not part of the
intent of GUIDs. GUIDs are somewhat random, and newsequentialid does away
with the randomness.


"sloan" wrote:

> Current Framework 2.0/3.0.
>
> ...
>
> In Sql Server, there is a way to generate consecutive guid's.
> newsequentialid.
>
> Is there a way to reproduce this type of consecutive guid's in the
> framework.
>
> I found some info about uuidgen , but that seems like a command line prompt
> tool, not a class library.
>
> I'd like to be able to throw an int value (N) at it, and it return N
> consecutive guid's.
>
>
> .........
>
>
> Here is a test stored procedure I wrote to show you what I'm talking about.
>
>
>
>
>
>
>
>
> IF EXISTS (SELECT * FROM sys.objects WHERE object_id =
> OBJECT_ID(N'[dbo].[uspNewSequentialUUIDCreateRange]') AND type in (N'P',
> N'PC'))
>
> DROP PROCEDURE [dbo].[uspNewSequentialUUIDCreateRange]
>
> GO
>
>
>
> CREATE PROCEDURE [dbo].[uspNewSequentialUUIDCreateRange] (
>
> @newUUIDCount int --return
>
> )
>
> AS
>
> SET NOCOUNT ON
>
> declare @t table ( dummyid int , entryid int identity(1,1) , uuid
> uniqueidentifier default newsequentialid() )
>
> insert into @t ( dummyid ) select top (@newUUIDCount) 0 from dbo.sysobjects
> so with (nolock)
>
> select entryid , uuid from @t
>
> SET NOCOUNT OFF
>
> GO
>
>
>
>
>
>
>
>
>
> /*
>
> --START TEST
>
> set nocount ON
>
> Create Table #HolderTable (entryid int , uuid uniqueidentifier )
>
> declare @NewUUIDCount int
>
> select @NewUUIDCount = 20
>
> INSERT INTO #HolderTable EXEC dbo.uspNewSequentialUUIDCreateRange
> @NewUUIDCount
>
>
>
> select * from #HolderTable
>
>
>
> DROP Table #HolderTable
>
> --END TEST CODE
>
>
>
> */
>
>
>

Mike,

Thanks for actually reading my post.

Yeah, I don't see a way to do it with System.Guid. ( I was already aware of
that class' existence ).

I may use my usp and push some sequential guid's up to the business layer,
since I'll already be in the database.
Or delay their creation until I'm pushing some data back into the tsql.

Oh well, I thought I'd ask.




"Family Tree Mike" <(E-Mail Removed)> wrote in
message news:764F289D-3021-4CFC-B53B-(E-Mail Removed)...
>I don't see a way to do this with the System.Guid class. newsequentialid
>was
> introduced to provide some optimization in SQL, but that was not part of
> the
> intent of GUIDs. GUIDs are somewhat random, and newsequentialid does away
> with the randomness.
>
>
> "sloan" wrote:
>
>> Current Framework 2.0/3.0.
>>
>> ...
>>
>> In Sql Server, there is a way to generate consecutive guid's.
>> newsequentialid.
>>
>> Is there a way to reproduce this type of consecutive guid's in the
>> framework.
>>
>> I found some info about uuidgen , but that seems like a command line
>> prompt
>> tool, not a class library.
>>
>> I'd like to be able to throw an int value (N) at it, and it return N
>> consecutive guid's.
>>
>>
>> .........
>>
>>
>> Here is a test stored procedure I wrote to show you what I'm talking
>> about.
>>
>>
>>
>>
>>
>>
>>
>>
>> IF EXISTS (SELECT * FROM sys.objects WHERE object_id =
>> OBJECT_ID(N'[dbo].[uspNewSequentialUUIDCreateRange]') AND type in (N'P',
>> N'PC'))
>>
>> DROP PROCEDURE [dbo].[uspNewSequentialUUIDCreateRange]
>>
>> GO
>>
>>
>>
>> CREATE PROCEDURE [dbo].[uspNewSequentialUUIDCreateRange] (
>>
>> @newUUIDCount int --return
>>
>> )
>>
>> AS
>>
>> SET NOCOUNT ON
>>
>> declare @t table ( dummyid int , entryid int identity(1,1) , uuid
>> uniqueidentifier default newsequentialid() )
>>
>> insert into @t ( dummyid ) select top (@newUUIDCount) 0 from
>> dbo.sysobjects
>> so with (nolock)
>>
>> select entryid , uuid from @t
>>
>> SET NOCOUNT OFF
>>
>> GO
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> /*
>>
>> --START TEST
>>
>> set nocount ON
>>
>> Create Table #HolderTable (entryid int , uuid uniqueidentifier )
>>
>> declare @NewUUIDCount int
>>
>> select @NewUUIDCount = 20
>>
>> INSERT INTO #HolderTable EXEC dbo.uspNewSequentialUUIDCreateRange
>> @NewUUIDCount
>>
>>
>>
>> select * from #HolderTable
>>
>>
>>
>> DROP Table #HolderTable
>>
>> --END TEST CODE
>>
>>
>>
>> */
>>
>>
>>

I don't understand - why do you need them to be sequential? Is it not enough
that each one is unique?
--
John Saunders | MVP - Connected System Developer

"John Saunders" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I don't understand - why do you need them to be sequential? Is it not
>enough that each one is unique?

If you are using them as a unique or primary key in a database such a SQL
server their highly random nature makes them less than desirable. Hence SQL
server provides the newsequentialid function which generates a form of Guid
which more predictable and when compared each new id is > than the previous.
This increases slightly the risk of collision but since the scope of use is
so narrow its beyond worrying about and yet provides a good basis for a
clustered key.



--
Anthony Jones - MVP ASP/ASP.NET

There are really good reasons to use a unique, sequential PK--most of the
reasons have to do with how the index pages are managed and index
fragmentation. While the NEWSEQUENTIALID is _UNIQUE_ it is not globally
unique unless the system has a NIC card (it uses the MAC address to generate
the uniqueness) so there is NO problem with concurrency in any case.

I quote from the doc: "Each GUID generated by using NEWSEQUENTIALID() is
unique on that computer. GUIDs generated by using NEWSEQUENTIALID() are
unique across multiple computers only if the source computer has a network
card."

hth

--
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
____________________________________________________________________________________________



"Anthony Jones" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "John Saunders" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>I don't understand - why do you need them to be sequential? Is it not
>>enough that each one is unique?
>
> If you are using them as a unique or primary key in a database such a SQL
> server their highly random nature makes them less than desirable. Hence
> SQL server provides the newsequentialid function which generates a form of
> Guid which more predictable and when compared each new id is > than the
> previous. This increases slightly the risk of collision but since the
> scope of use is so narrow its beyond worrying about and yet provides a
> good basis for a clustered key.
>
>
>
> --
> Anthony Jones - MVP ASP/ASP.NET
>

Ding Ding Ding Ding Ding!

That's for explaining it, so I didn't have to. I'm worn out this week.

.....................

And sometimes we build our relationships OUTSIDE of the database, and shoot
them in via xml.
And we use a surrogate key......and with set based inserts......a
consecutive guid would be beneficial.

We have been relying on the newsequentialid (as the default value for the
uniqueidentifier primary key), but I was going to experiment with creating
the surrogate key outside of the database and pushing it in instead.

..............

This was experimentation stuff. And trying to figure out if having them
generated outside of the db provided any benefit.

One of the biggest wait stats we have is
PAGELATCH_EX.

I'm not a dba, I'm not trying to experiment to see if the "outside
sequential guid" creation might help.



Maybe someone can comment on the

PAGELATCH_EX ... and if I'm barking up the wrong tree or not.




PAGELATCH_EX

True
Occurs when a task is waiting for a latch for a buffer that is not in
an I/O request. The latch request is in Exclusive mode.

Contention can be caused by issues other than IO or memory
performance, for example, heavy concurrent inserts into the same index range
can cause this kind of contention. If many inserts must be added on the same
page, they are serialized using the latch. Lots of inserts into the same
range can also cause page splits in the index which holds onto the latch
while allocating a new page (this can take time). Any read accesses to the
same range as the inserts would also conflict on the latches. The solution
in these cases is to distribute the inserts using a more appropriate index.




"Anthony Jones" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "John Saunders" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>I don't understand - why do you need them to be sequential? Is it not
>>enough that each one is unique?
>
> If you are using them as a unique or primary key in a database such a SQL
> server their highly random nature makes them less than desirable. Hence
> SQL server provides the newsequentialid function which generates a form of
> Guid which more predictable and when compared each new id is > than the
> previous. This increases slightly the risk of collision but since the
> scope of use is so narrow its beyond worrying about and yet provides a
> good basis for a clustered key.
>
>
>
> --
> Anthony Jones - MVP ASP/ASP.NET
>

> If you are using them as a unique or primary key in a database such a SQL
> server their highly random nature makes them less than desirable. Hence
> SQL server provides the newsequentialid function which generates a form of
> Guid

Why/when would that be preferable over just using an incremental numeric ID
field?

-Darrel

When you need to merge N number of databases.
Yes, there are "identity" workarounds, but if you ever need to merge massive
databases, using GUID's makes it easier.


Replicating IDENTITY's is a big headache as well.




"darrel" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>> If you are using them as a unique or primary key in a database such a SQL
>> server their highly random nature makes them less than desirable. Hence
>> SQL server provides the newsequentialid function which generates a form
>> of Guid
>
> Why/when would that be preferable over just using an incremental numeric
> ID field?
>
> -Darrel