Is there an equivalent class function in C# to generate sequencial guid just
like the NewSequentialID() function in SQL Server 2005?
14  6532 
Roy,
Since each Guid by definition is completely unique, there could never
be such as thing as a "Sequential Guid". If you need identifiers that
are unique, you should consider using another method. A static double
with an initial value and a method that simply increments this would
do the trick. If it needs to be a string, you can take the ToString()
method on it.
Peter
Roy,
You can use the UuidCreateSequential API function through the P/Invoke
layer.
For more info, check out the entry on pinvoke.net: http://www.pinvoke.net/default.aspx/...equential.html
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Roy" <Ro*@discussions.microsoft.comwrote in message
news:80**********************************@microsof t.com...
Is there an equivalent class function in C# to generate sequencial guid
just
like the NewSequentialID() function in SQL Server 2005?
Hello Nicholas Paldino [.NET/C# MVP],
hmm, awesome
But why MS desided make guids sequential? Are there any practical reasons
for this?
NRoy,
N>
NYou can use the UuidCreateSequential API function through the
NP/Invoke layer.
N>
NFor more info, check out the entry on pinvoke.net:
N>
N http://www.pinvoke.net/default.aspx/...equential.html
N>
NHope this helps.
N>
N"Roy" <Ro*@discussions.microsoft.comwrote in message
Nnews:80**********************************@microso ft.com...
N>
>Is there an equivalent class function in C# to generate sequencial
guid
just
like the NewSequentialID() function in SQL Server 2005?
---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour
"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche
Michael,
They didn't decide to make them sequential, they just gave an
opportunity to generate them should people need them? I would NOT use these
if I needed to create a unique number, but only if I needed to create a
sequential 128-bit number.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Michael Nemtsev" <ne*****@msn.comwrote in message
news:17***************************@msnews.microsof t.com...
Hello Nicholas Paldino [.NET/C# MVP],
hmm, awesome But why MS desided make guids sequential? Are there any
practical reasons for this?
NRoy,
NNYou can use the UuidCreateSequential API function through the
NP/Invoke layer.
NNFor more info, check out the entry on pinvoke.net:
NNhttp://www.pinvoke.net/default.aspx/...equential.html
NNHope this helps.
NN"Roy" <Ro*@discussions.microsoft.comwrote in message
Nnews:80**********************************@microso ft.com...
N>
>>Is there an equivalent class function in C# to generate sequencial
guid
just
like the NewSequentialID() function in SQL Server 2005?
---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour
"At times one remains faithful to a cause only because its opponents do
not cease to be insipid." (c) Friedrich Nietzsche
"Michael Nemtsev" <ne*****@msn.comwrote in message
news:17***************************@msnews.microsof t.com...
Hello Nicholas Paldino [.NET/C# MVP],
hmm, awesome But why MS desided make guids sequential? Are there any
practical reasons for this?
One common use of sequential GUIDs is when you have a bunch of COM objects
that are all related and you want an easy way of organizing them. Even if
all that means is that they show up next to each other in the registry,
that's sort of useful. There may also be some purpose to being able to
quickly convert from a GUID to a 0-based index.
I suppose one could debate the exact degree of benefit from that sort of
thing, but the fact remains that those are possible reasons for wanting GUID
in sequential order.
Pete
Peter Duniho wrote:
"Michael Nemtsev" <ne*****@msn.comwrote in message
news:17***************************@msnews.microsof t.com...
>Hello Nicholas Paldino [.NET/C# MVP],
hmm, awesome But why MS desided make guids sequential? Are there any
practical reasons for this?
One common use of sequential GUIDs is when you have a bunch of COM objects
that are all related and you want an easy way of organizing them. Even if
all that means is that they show up next to each other in the registry,
that's sort of useful. There may also be some purpose to being able to
quickly convert from a GUID to a 0-based index.
I suppose one could debate the exact degree of benefit from that sort of
thing, but the fact remains that those are possible reasons for wanting GUID
in sequential order.
Also, having a clustered index on GUID column in the database table
makes more sense if it is sequential.
Keep in mind though, that you aren't allocating multiple UUIDs in one call
to the OS. Therefore, you could have conditions where other
threads/processes are also calling the same API thus making your results not
a contiguous set of "numbers".
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.comwrote in
message news:eK**************@TK2MSFTNGP03.phx.gbl...
Michael,
They didn't decide to make them sequential, they just gave an
opportunity to generate them should people need them? I would NOT use
these if I needed to create a unique number, but only if I needed to
create a sequential 128-bit number.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Michael Nemtsev" <ne*****@msn.comwrote in message
news:17***************************@msnews.microsof t.com...
>Hello Nicholas Paldino [.NET/C# MVP],
hmm, awesome But why MS desided make guids sequential? Are there any
practical reasons for this?
NRoy,
NNYou can use the UuidCreateSequential API function through the
NP/Invoke layer.
NNFor more info, check out the entry on pinvoke.net:
NN>
http://www.pinvoke.net/default.aspx/...equential.html
NNHope this helps.
NN"Roy" <Ro*@discussions.microsoft.comwrote in message
Nnews:80**********************************@micros oft.com...
N>
>>>Is there an equivalent class function in C# to generate sequencial
guid
just
like the NewSequentialID() function in SQL Server 2005?
---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour
"At times one remains faithful to a cause only because its opponents do
not cease to be insipid." (c) Friedrich Nietzsche
Hi,
I don't think so. I thought the point of a clustered index was to order the data rows against the index. The index is sorted no
matter the type of the column or the values that it contains.
--
Dave Sexton
"Sericinus hunter" <se*****@flash.netwrote in message news:%2****************@TK2MSFTNGP04.phx.gbl...
Peter Duniho wrote:
>"Michael Nemtsev" <ne*****@msn.comwrote in message news:17***************************@msnews.microsof t.com...
>>Hello Nicholas Paldino [.NET/C# MVP],
hmm, awesome But why MS desided make guids sequential? Are there any practical reasons for this?
One common use of sequential GUIDs is when you have a bunch of COM objects that are all related and you want an easy way of
organizing them. Even if all that means is that they show up next to each other in the registry, that's sort of useful. There
may also be some purpose to being able to quickly convert from a GUID to a 0-based index.
I suppose one could debate the exact degree of benefit from that sort of thing, but the fact remains that those are possible
reasons for wanting GUID in sequential order.
Also, having a clustered index on GUID column in the database table
makes more sense if it is sequential.
"Sericinus hunter" <se*****@flash.netwrote in message news:%2****************@TK2MSFTNGP04.phx.gbl...
>>
Also, having a clustered index on GUID column in the database table
makes more sense if it is sequential.
Dave Sexton wrote:
Hi,
I don't think so. I thought the point of a clustered index was to order the data rows against the index. The index is sorted no
matter the type of the column or the values that it contains.
This is true. But GUID by itself does not make sense of being sorted.
If you create a clustered index on GUID column then you will likely
see more page splits during insert operations than you normally want,
because new rows will have GUID values all across the range of existing
values. With sequential GUID this can be avoided. I think that was the
primary reason for introducing sequential GUIDs.
Hi,
I don't believe that it makes more sense to have sequential guids as the values in your column, however I do believe it's required
to have the values sorted in a clustered index. Because of that requirement the DBMS will sort on your column, so I don't think it
really matters whether the values appear sequentially in the table.
In SQL Server, there is no mention in the documentation about sequential guids and there is no function AFAIK that will create them.
When inserting rows into the table with that column, one usually uses the newid() function to populate it, which does not produce
sequential guids. When you create a unique clustered index on a uniqueidentifier column the index will sort on the values in that
column, and because of its clustered nature, the data rows will be sorted based on the sort of the index.
Now, if I'm mistaken on any part of this please let me know. I don't claim to be an expert on this, and I really don't understand
your reasoning.
--
Dave Sexton
"Sericinus hunter" <se*****@flash.netwrote in message news:eA****************@TK2MSFTNGP02.phx.gbl...
"Sericinus hunter" <se*****@flash.netwrote in message news:%2****************@TK2MSFTNGP04.phx.gbl...
>
Also, having a clustered index on GUID column in the database table
makes more sense if it is sequential.
Dave Sexton wrote:
>Hi,
I don't think so. I thought the point of a clustered index was to order the data rows against the index. The index is sorted no
matter the type of the column or the values that it contains.
This is true. But GUID by itself does not make sense of being sorted.
If you create a clustered index on GUID column then you will likely
see more page splits during insert operations than you normally want,
because new rows will have GUID values all across the range of existing
values. With sequential GUID this can be avoided. I think that was the
primary reason for introducing sequential GUIDs.
Dave Sexton wrote:
Hi,
I don't believe that it makes more sense to have sequential guids as the values in your column, however I do believe it's required
to have the values sorted in a clustered index. Because of that requirement the DBMS will sort on your column, so I don't think it
really matters whether the values appear sequentially in the table.
In SQL Server, there is no mention in the documentation about sequential guids and there is no function AFAIK that will create them.
There is. They introduced it with SQL Server 2005.
When inserting rows into the table with that column, one usually uses the newid() function to populate it, which does not produce
sequential guids.
And now you can use newsequentialid() function. Although it works only
in default constraint declarations.
When you create a unique clustered index on a uniqueidentifier column the index will sort on the values in that
column, and because of its clustered nature, the data rows will be sorted based on the sort of the index.
Yes, but here how it works during inserts. With clustered index,
the data row must physically go to right place in the storage because,
as you correctly said, the whole row, i.e the data itself is sorted.
Now imagine that a new row is inserted and its GUID value is somewhere
in the middle of the range of already existing (and sorted) rows. This
is very likely due to random nature of GUID. The row goes in the middle,
and all the rows from that point to the end must be physically rearranged
on the disk. Performance-wise this can be very costly. With sequential
GUID on the other hand, you always add the row to the end of physical
storage, thus making inserts much more effective.
Hi,
>I don't believe that it makes more sense to have sequential guids as the values in your column, however I do believe it's
required to have the values sorted in a clustered index. Because of that requirement the DBMS will sort on your column, so I
don't think it really matters whether the values appear sequentially in the table.
In SQL Server, there is no mention in the documentation about sequential guids and there is no function AFAIK that will create
them.
There is. They introduced it with SQL Server 2005.
>When inserting rows into the table with that column, one usually uses the newid() function to populate it, which does not produce
sequential guids.
And now you can use newsequentialid() function. Although it works only
in default constraint declarations.
Interesting. I searched for "sequential" alone and in combination with other terms before I wrote my last post, and that function
didn't show up in any of the results (SQL Server 2005 Help System: Local and MSDN). Also, documentation for the standard functions
and keywords such as uniqueidentifier, newid() and ROWGUIDCOL in the column definition topics and CREATE TABLE topics do not link to
that function, at least not directly. And as a matter of fact, they all still recommend to use newid().
Thanks for the info.
>When you create a unique clustered index on a uniqueidentifier column the index will sort on the values in that column, and
because of its clustered nature, the data rows will be sorted based on the sort of the index.
Yes, but here how it works during inserts. With clustered index,
the data row must physically go to right place in the storage because,
as you correctly said, the whole row, i.e the data itself is sorted.
Now imagine that a new row is inserted and its GUID value is somewhere
in the middle of the range of already existing (and sorted) rows. This
is very likely due to random nature of GUID. The row goes in the middle,
and all the rows from that point to the end must be physically rearranged
on the disk. Performance-wise this can be very costly. With sequential
GUID on the other hand, you always add the row to the end of physical
storage, thus making inserts much more effective.
Thanks for the explanation. Your original statement is much clearer to me now.
--
Dave Sexton
Is the primary access going to be by guid? If not, you might want to create
the primary key index nonclustered and create a clustered index on an
alternate key (assuming the table has an alternate key).
"Sericinus hunter" <se*****@flash.netwrote in message
news:Oe****************@TK2MSFTNGP02.phx.gbl...
Dave Sexton wrote:
>Hi,
I don't believe that it makes more sense to have sequential guids as the
values in your column, however I do believe it's required to have the
values sorted in a clustered index. Because of that requirement the DBMS
will sort on your column, so I don't think it really matters whether the
values appear sequentially in the table.
In SQL Server, there is no mention in the documentation about sequential
guids and there is no function AFAIK that will create them.
There is. They introduced it with SQL Server 2005.
>When inserting rows into the table with that column, one usually uses the
newid() function to populate it, which does not produce sequential guids.
And now you can use newsequentialid() function. Although it works only
in default constraint declarations.
>When you create a unique clustered index on a uniqueidentifier column the
index will sort on the values in that column, and because of its
clustered nature, the data rows will be sorted based on the sort of the
index.
Yes, but here how it works during inserts. With clustered index,
the data row must physically go to right place in the storage because,
as you correctly said, the whole row, i.e the data itself is sorted.
Now imagine that a new row is inserted and its GUID value is somewhere
in the middle of the range of already existing (and sorted) rows. This
is very likely due to random nature of GUID. The row goes in the middle,
and all the rows from that point to the end must be physically rearranged
on the disk. Performance-wise this can be very costly. With sequential
GUID on the other hand, you always add the row to the end of physical
storage, thus making inserts much more effective.
Well, yes, choosing on what columns to create a clustered index on is
a completely different issue. Personally, I believe that building it on
a GUID column is rarely a good idea.
And it is not necessary to build it on key columns, any column(s)
can be candidate.
Noah Sham wrote:
Is the primary access going to be by guid? If not, you might want to create
the primary key index nonclustered and create a clustered index on an
alternate key (assuming the table has an alternate key).
"Sericinus hunter" <se*****@flash.netwrote in message
news:Oe****************@TK2MSFTNGP02.phx.gbl...
>Dave Sexton wrote:
>>Hi,
I don't believe that it makes more sense to have sequential guids as the
values in your column, however I do believe it's required to have the
values sorted in a clustered index. Because of that requirement the DBMS
will sort on your column, so I don't think it really matters whether the
values appear sequentially in the table.
In SQL Server, there is no mention in the documentation about sequential
guids and there is no function AFAIK that will create them.
There is. They introduced it with SQL Server 2005.
>>When inserting rows into the table with that column, one usually uses the
newid() function to populate it, which does not produce sequential guids.
And now you can use newsequentialid() function. Although it works only
in default constraint declarations.
>>When you create a unique clustered index on a uniqueidentifier column the
index will sort on the values in that column, and because of its
clustered nature, the data rows will be sorted based on the sort of the
index.
Yes, but here how it works during inserts. With clustered index,
the data row must physically go to right place in the storage because,
as you correctly said, the whole row, i.e the data itself is sorted.
Now imagine that a new row is inserted and its GUID value is somewhere
in the middle of the range of already existing (and sorted) rows. This
is very likely due to random nature of GUID. The row goes in the middle,
and all the rows from that point to the end must be physically rearranged
on the disk. Performance-wise this can be very costly. With sequential
GUID on the other hand, you always add the row to the end of physical
storage, thus making inserts much more effective.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Louis Frolio |
last post by:
Greetings All, I have read many upon many articles here regarding GUID
data types and uniqueness. There have been many opinions regarding
the effectiveness of GUID's and when they should/should...
|
by: Richard Setford |
last post by:
Hi there,
Bit of an Access newbie here in need of some help. First time in here so
please be gentle with me.
Here's what I'm trying to achieve. I want to build a database which
records the...
|
by: Rene |
last post by:
I am using the Guid.Empty value ("00000000-0000-0000-0000-000000000000") to
represent a special meaning. The problem is that I don't know if there is a
chance that a command like...
|
by: Nak |
last post by:
Hi there,
Does anyone know how I would get the value of the assembly GUID in code
from within the same application? Thanks in advance.
Nick.
--...
|
by: rcolby |
last post by:
Evening,
Wondering if someone can point me in the right direction, on how I would
compare a system.guid with a system.byte.
system.guid (pulled from sql server table with a data type of...
|
by: George |
last post by:
I want to create a unique id for each of a set of objects.
These ids may be generated on multiple machines simultaneously and must all
be different to each other.
There are an undefined number...
|
by: Wolf |
last post by:
Hi
I am trying to set a property(PartyHomeAddressID) = to a guid in a ini
file.
But everytime when the ini file has an empty guid it breaks with an
error tellin me a guid is 32 char long with 4...
|
by: Michael Primeaux |
last post by:
I have a simple .NET 2.0 web service created with VS.NET 2005 with a single
web method with the following signature:
void HelloWorld(Guid parameter1);
When calling this method I receive the...
|
by: Troll |
last post by:
Windows XP Pro
VS 2005 & C# (I'm fairly new to C# but have doing VB.Net going on 2yrs and VB6 for 5yrs.)
I'm using C# to build a custom RSS generator. I'm having trouble building the guid...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
