Retrieving the new defalt value of a uniqueidentifier
-
I created a set of tables in which the primary keys are set to uniqueidentifiers with a default value of newid(), which is the function that generate new guids in Transact-SQL. While I can create a uniqueidentifier variable and initialize it before inserting a row, that would obviate the reason for creating a default value in the first place. But unlike an identity field, there is no function, that I can think of that would retrieve the most recently created uniqueidentifier. I would like to use this value within the body of a stored procedure but I can't think of any way to get it short of creating it ahead of time and not using the default value mechanism. I could access the new value in a trigger, but then how would I pass that back to the stored procedure? I don't think that a trigger is the way to do this, but I don't know. Can anyone show me a way to do this?
-
I created a set of tables in which the primary keys are set to uniqueidentifiers with a default value of newid(), which is the function that generate new guids in Transact-SQL. While I can create a uniqueidentifier variable and initialize it before inserting a row, that would obviate the reason for creating a default value in the first place. But unlike an identity field, there is no function, that I can think of that would retrieve the most recently created uniqueidentifier. I would like to use this value within the body of a stored procedure but I can't think of any way to get it short of creating it ahead of time and not using the default value mechanism. I could access the new value in a trigger, but then how would I pass that back to the stored procedure? I don't think that a trigger is the way to do this, but I don't know. Can anyone show me a way to do this?
I hate GIUDs I do not use the default value, instead I create the GUID (in the stored proc) before inserting and therefore already have it for the return select or an out parameter.
Never underestimate the power of human stupidity RAH
-
I created a set of tables in which the primary keys are set to uniqueidentifiers with a default value of newid(), which is the function that generate new guids in Transact-SQL. While I can create a uniqueidentifier variable and initialize it before inserting a row, that would obviate the reason for creating a default value in the first place. But unlike an identity field, there is no function, that I can think of that would retrieve the most recently created uniqueidentifier. I would like to use this value within the body of a stored procedure but I can't think of any way to get it short of creating it ahead of time and not using the default value mechanism. I could access the new value in a trigger, but then how would I pass that back to the stored procedure? I don't think that a trigger is the way to do this, but I don't know. Can anyone show me a way to do this?
I am rather fond of GUIDs. They are so much better than lowly ints. I can create a hierarchy of various rows and insert them all in one swell foop, rather than doing one, getting its ID, passing that to the next... X| I do set the default value, as you did, but that merely gives me flexibility -- in some cases I may not need to know the ID, in others I may; so I can either set it myself or let it default, depending on need. If you don't want to use the default value, don't set it, big fat hairy deal. Autoincrement fields X| are a nasty kludge that never should have been implemented -- as I recall, in Oracle we used "sequences" which allowed us to get the "next value" much like we can get a new GUID. When the company I worked for started to shift from Oracle to SQL Server, we implemented our own sequences, we never used autoincrement fields -- I still never have.
-
I am rather fond of GUIDs. They are so much better than lowly ints. I can create a hierarchy of various rows and insert them all in one swell foop, rather than doing one, getting its ID, passing that to the next... X| I do set the default value, as you did, but that merely gives me flexibility -- in some cases I may not need to know the ID, in others I may; so I can either set it myself or let it default, depending on need. If you don't want to use the default value, don't set it, big fat hairy deal. Autoincrement fields X| are a nasty kludge that never should have been implemented -- as I recall, in Oracle we used "sequences" which allowed us to get the "next value" much like we can get a new GUID. When the company I worked for started to shift from Oracle to SQL Server, we implemented our own sequences, we never used autoincrement fields -- I still never have.
So, I have one person that hates GUIDS and one that likes them. I chose them for the absolute certainty that there would be no collisions in IDs between tables and / or systems. My main goal was that I wanted to uniquely identify any object in my application. I won't have that many objects that I could not have used integers, but with integers to do that amoung many tables I would have to devise some sort of function that always delivered a new unique one when creating a row in any table. If I could build a suitable function I still might do that. I probably could do so by using a single row table with one tuple holding the last integer used, but I have not tried that yet. One thing I don't understand is why Microsoft created unsigned integers in all its programing languages, but did not provide the same feature in SQL server. I really do not want to use negative values, but the fact that there is no unsigned integer cuts my value pool in half if I choose to start with zero. I also had some Oracle experience and I think I remember the sequence object. I don't know why Microsoft didn't implement something similar. For my part I would like to see sequences that deliver either unique unsigned integers or unique unsigned doubles. That would handle virtually any system that I can think of as a means of generating unique keys I have been taught that SQL Server is much faster when dealing with integer keys because it uses integer arithmatic in its underlying calculations. Is this correct? And if so, how much faster would it be? For now, I have chosen to create the IDs before inserting the rows so I already have them for other purposes. I have tables that serve as links for many to many relationships and that is where I am using the IDs. My next challenge is to figure out how to maintain data for directed acyclic graphs, the idea of being able to show the relationships between any object in the system to any other object in the system even if that realtionship is a remote relationship like a grandparent of a cousin object, etc. I have found one article on Code project regarding that task, but I am looking for more to see if there are other ways to do this and so that I can understand the process better.
-
So, I have one person that hates GUIDS and one that likes them. I chose them for the absolute certainty that there would be no collisions in IDs between tables and / or systems. My main goal was that I wanted to uniquely identify any object in my application. I won't have that many objects that I could not have used integers, but with integers to do that amoung many tables I would have to devise some sort of function that always delivered a new unique one when creating a row in any table. If I could build a suitable function I still might do that. I probably could do so by using a single row table with one tuple holding the last integer used, but I have not tried that yet. One thing I don't understand is why Microsoft created unsigned integers in all its programing languages, but did not provide the same feature in SQL server. I really do not want to use negative values, but the fact that there is no unsigned integer cuts my value pool in half if I choose to start with zero. I also had some Oracle experience and I think I remember the sequence object. I don't know why Microsoft didn't implement something similar. For my part I would like to see sequences that deliver either unique unsigned integers or unique unsigned doubles. That would handle virtually any system that I can think of as a means of generating unique keys I have been taught that SQL Server is much faster when dealing with integer keys because it uses integer arithmatic in its underlying calculations. Is this correct? And if so, how much faster would it be? For now, I have chosen to create the IDs before inserting the rows so I already have them for other purposes. I have tables that serve as links for many to many relationships and that is where I am using the IDs. My next challenge is to figure out how to maintain data for directed acyclic graphs, the idea of being able to show the relationships between any object in the system to any other object in the system even if that realtionship is a remote relationship like a grandparent of a cousin object, etc. I have found one article on Code project regarding that task, but I am looking for more to see if there are other ways to do this and so that I can understand the process better.
henry1951 wrote:
If I could build a suitable function I still might do that. I probably could do so by using a single row table with one tuple holding the last integer used, but I have not tried that yet.
I think what we* did was create a multi-row table that supported multiple "sequences" -- the app could request the next value for the User sequence, or the Transaction sequence, etc. It also had fields for Min and Max -- if the sequence reached the Max it would wrap around to the Min (I assume that there was a need for that in one of the apps). * Not that I was involved in that effort at the early stages. Wish I had been -- the idiots put data access in the UI layer :mad: .
henry1951 wrote:
unsigned integers
Yeah.
henry1951 wrote:
faster when dealing with integer
Well, they're smaller, quicker to compare. But I don't consider that to be a reason to select them over GUIDs -- just don't use strings as keys X| .
-
I am rather fond of GUIDs. They are so much better than lowly ints. I can create a hierarchy of various rows and insert them all in one swell foop, rather than doing one, getting its ID, passing that to the next... X| I do set the default value, as you did, but that merely gives me flexibility -- in some cases I may not need to know the ID, in others I may; so I can either set it myself or let it default, depending on need. If you don't want to use the default value, don't set it, big fat hairy deal. Autoincrement fields X| are a nasty kludge that never should have been implemented -- as I recall, in Oracle we used "sequences" which allowed us to get the "next value" much like we can get a new GUID. When the company I worked for started to shift from Oracle to SQL Server, we implemented our own sequences, we never used autoincrement fields -- I still never have.
PIEBALDconsult wrote:
in Oracle we used "sequences"
And the practical difference between a ident and a sequence is? I hate guids b/c I'm lazy, have you ever tried to remember a guid, when monkeying with the data I spend a lot of time chasing down problems in the data, as I;m the developer the numbers are generally nice and small, I can manage to remember 1 or even 2 but a guid, not a chance. I got sick of ctrl c ctrl v every time I want to find a record.
Never underestimate the power of human stupidity RAH
-
PIEBALDconsult wrote:
in Oracle we used "sequences"
And the practical difference between a ident and a sequence is? I hate guids b/c I'm lazy, have you ever tried to remember a guid, when monkeying with the data I spend a lot of time chasing down problems in the data, as I;m the developer the numbers are generally nice and small, I can manage to remember 1 or even 2 but a guid, not a chance. I got sick of ctrl c ctrl v every time I want to find a record.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
And the practical difference between a ident and a sequence is?
Sequences aren't tied to a particular table. You can get a value from a sequence without adding a record. I suppose one could implement a sequence using a table with only an autoincrement column -- and perhaps a trigger to delete the otherwise needless rows. :-D
Mycroft Holmes wrote:
I spend a lot of time chasing down problems in the data
I don't. :-D And I don't write bugs either. :-D Eventually, your numbers may be high enough that you can't remember them* -- GUIDs simply get you there immediately, that's one of the benefits. Or you could cobble up your own GUIDs during development and testing:
System.Guid g = new System.Guid ( 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 1 ) ;You could even wrap that around a sequence. You get the best of both worlds. * For me that's anything with more than three digits. -
Mycroft Holmes wrote:
And the practical difference between a ident and a sequence is?
Sequences aren't tied to a particular table. You can get a value from a sequence without adding a record. I suppose one could implement a sequence using a table with only an autoincrement column -- and perhaps a trigger to delete the otherwise needless rows. :-D
Mycroft Holmes wrote:
I spend a lot of time chasing down problems in the data
I don't. :-D And I don't write bugs either. :-D Eventually, your numbers may be high enough that you can't remember them* -- GUIDs simply get you there immediately, that's one of the benefits. Or you could cobble up your own GUIDs during development and testing:
System.Guid g = new System.Guid ( 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 1 ) ;You could even wrap that around a sequence. You get the best of both worlds. * For me that's anything with more than three digits.PIEBALDconsult wrote:
Sequences aren't tied to a particular table. You can get a value from a sequence without adding a record
Interesting, I automatically created a sequence for each table, habit from SQL Server I guess. 90% of my work seems to dragging data from crappily designed legacy systems (not sure if it is the design or the interface) and trying to make sense of the data, reverse engineering someone elses disaster :sigh: . There rare times I do get a transacional app to build I treasure immensly as these are areas that are new and fresh to me.
Never underestimate the power of human stupidity RAH
-
So, I have one person that hates GUIDS and one that likes them. I chose them for the absolute certainty that there would be no collisions in IDs between tables and / or systems. My main goal was that I wanted to uniquely identify any object in my application. I won't have that many objects that I could not have used integers, but with integers to do that amoung many tables I would have to devise some sort of function that always delivered a new unique one when creating a row in any table. If I could build a suitable function I still might do that. I probably could do so by using a single row table with one tuple holding the last integer used, but I have not tried that yet. One thing I don't understand is why Microsoft created unsigned integers in all its programing languages, but did not provide the same feature in SQL server. I really do not want to use negative values, but the fact that there is no unsigned integer cuts my value pool in half if I choose to start with zero. I also had some Oracle experience and I think I remember the sequence object. I don't know why Microsoft didn't implement something similar. For my part I would like to see sequences that deliver either unique unsigned integers or unique unsigned doubles. That would handle virtually any system that I can think of as a means of generating unique keys I have been taught that SQL Server is much faster when dealing with integer keys because it uses integer arithmatic in its underlying calculations. Is this correct? And if so, how much faster would it be? For now, I have chosen to create the IDs before inserting the rows so I already have them for other purposes. I have tables that serve as links for many to many relationships and that is where I am using the IDs. My next challenge is to figure out how to maintain data for directed acyclic graphs, the idea of being able to show the relationships between any object in the system to any other object in the system even if that realtionship is a remote relationship like a grandparent of a cousin object, etc. I have found one article on Code project regarding that task, but I am looking for more to see if there are other ways to do this and so that I can understand the process better.
henry1951 wrote:
I chose them for the absolute certainty that there would be no collisions in IDs
Actually it's not an absolute certainty. It's just that the chance of a collision is extremely small. Be careful using GUIDs as PKs. Significant performance issues can arise (both time and space are wasted) when the clustering index is a GUID and the default in SQLServer is to create a clustering index on the PK. You can get around this by using the newsequentialid()function or by generating your own sequential GUIDs. See this article[^]for a discussion of the issue.