Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

IDENTITY_INSERT, and Using Alphanumeric Autoincrement Primary Key Expand / Collapse
Author
Message
Posted Tuesday, June 25, 2013 2:26 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, July 24, 2014 12:29 PM
Points: 54, Visits: 101
Hi Folks,

Thanks again to every1 looking into this for me.
I was in need to generate Alphanumeric ID ( An Identity which is based on PRIMARY KEY [assigned to every row for an user information] AND User Status [Suppose Status can have values {A,B,C,D,E}]
So the Alphanumeric ID for First user could be '1A', Similarly second user '2A', Third '3B', Fourth '4A'.. and some nth user has 'nE'.
So now,
I've found the logic to Derive this Alphanumeric ID.
Of course, It cannot be a Primary KEY so my assumption about it was false tough it can be a UNIQUE KEY.

The logic is as below,
UPDATE EMP_DETAILS SET Use_ID = CAST((EMP_STATUS+''+CAST(ID as varchar)) as varchar)
Where
EMP_DETAILS: Table for User information.
ID: Primary Key & EMP_STATUS[As the user chooses from Front end]

But finally, what i got is I have to re-look to the written records and re-process for the USE_ID(the required Alpha numeric ID).

So my question is, Is there any other way like to achieve this, alike the derived columns are(Value get calculated and store automatically)?

Post #1467381
Posted Tuesday, June 25, 2013 10:42 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Sunday, September 29, 2013 1:24 AM
Points: 429, Visits: 1,721
kiran.vaichalkar (6/25/2013)
Hi Folks,

Thanks again to every1 looking into this for me.
I was in need to generate Alphanumeric ID ( An Identity which is based on PRIMARY KEY [assigned to every row for an user information] AND User Status [Suppose Status can have values {A,B,C,D,E}]
So the Alphanumeric ID for First user could be '1A', Similarly second user '2A', Third '3B', Fourth '4A'.. and some nth user has 'nE'.
So now,
I've found the logic to Derive this Alphanumeric ID.
Of course, It cannot be a Primary KEY so my assumption about it was false tough it can be a UNIQUE KEY.

The logic is as below,
UPDATE EMP_DETAILS SET Use_ID = CAST((EMP_STATUS+''+CAST(ID as varchar)) as varchar)
Where
EMP_DETAILS: Table for User information.
ID: Primary Key & EMP_STATUS[As the user chooses from Front end]

But finally, what i got is I have to re-look to the written records and re-process for the USE_ID(the required Alpha numeric ID).

So my question is, Is there any other way like to achieve this, alike the derived columns are(Value get calculated and store automatically)?



So what happens when you get to 26Z? What would 27 be? Perhaps 27AA, 28AB, etc?

I'm trying to be practical here. Really, with enough ingenuity we can do just about anything we want in SQL. I don't question as much as others as to WHY people have unusual requirements. Sometimes we just do because a client or some other power-that-be has made the request and either won't change or it's just not worth the bother.

So in that vein of thought, you CAN do this but not with an identity column which is of course always and only numeric. What you'll probably need to do is create a computed column to hold the alphanumeric value. The function/formula for that computed column will then have to get the identity value and using some algorithm determine the letter combination that would be next in sequence. To get alpha characters from a number you can use the CHAR operator.

For example, you can easily convert the number 67 into its ASCII equivalent,
which in this case is an upper-case 'C', and back again.


SELECT CHAR(67) -- returns 'C'

--this does the opposite
SELECT ASCII('C') -- returns '67'


So with that, you could do your string manipulations. But it will get complicated once you get past that first 'Z'! I've been trying to do something like that for awhile as an experiment and it never seems to work correctly and then the code turns into spaghetti.

Probably the best method would be a table of characters similar to a tally table:

ID INT IDENTITY(1,!)
VAL VARCHAR(5)

The values would be like this or whatever pattern you choose:

1 A
2 B
...
26 Z
27 AA
28 AB
...
53 AZ
54 AAA
55 AAB
...
80 AAAA
81 AAAB

Then you do a JOIN on a tally table with the IDENTITY value to concatenate your artificial key into a single string.





Post #1467447
Posted Wednesday, June 26, 2013 7:45 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 3:28 PM
Points: 13,103, Visits: 11,933
Steven Willis (6/25/2013)

So in that vein of thought, you CAN do this but not with an identity column which is of course always and only numeric.


Just because you CAN do something does not mean it is a good idea. The whole concept of this is going to be nothing but a complete and total PITA. All kinds of hoops to create the keys, concurrency is a serious concern when you have a table to hold your keys. This thing can and will backfire at some point. It all comes back to what is the gain here?


_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Post #1467665
Posted Wednesday, June 26, 2013 10:38 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Sunday, September 29, 2013 1:24 AM
Points: 429, Visits: 1,721
Sean Lange (6/26/2013)
Steven Willis (6/25/2013)

So in that vein of thought, you CAN do this but not with an identity column which is of course always and only numeric.


Just because you CAN do something does not mean it is a good idea. The whole concept of this is going to be nothing but a complete and total PITA. All kinds of hoops to create the keys, concurrency is a serious concern when you have a table to hold your keys. This thing can and will backfire at some point. It all comes back to what is the gain here?

Sean

I agree that using such an artificial "key" would be a horrible idea and didn't mean to imply that such values should be part of a primary key. But I can see where a computed column approach to create something like an ascending aphanumeric code BASED on an identity value might be useful as part of an employee ID, badge number, or whatever.

Not too many months ago I had a requirement to generate unique registration codes to be handed out to users who would use the code to validate their login. This was a "use-once" code so that the user could login once. The site admins wanted the codes to be sequential because they thought it would be easier for them to administer the codes. I pointed out that if the codes were sequential, anyone with a brain could figure out the sequence from the one authorized code they were given and screw things up. Not to mention the aforementioned difficulties of even doing this as this thread demonstrates. So wisely they took my advice to use random codes.

Now I understand that SQL2012 has a sequential alphanumeric function of some sort, though I haven't seen or tried it yet. So I guess as we all eventually upgrade over the next few years the point will be moot.

Steve

 
Post #1467771
Posted Wednesday, June 26, 2013 11:44 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 3:28 PM
Points: 13,103, Visits: 11,933
Steven Willis (6/26/2013)
Sean Lange (6/26/2013)
Steven Willis (6/25/2013)

So in that vein of thought, you CAN do this but not with an identity column which is of course always and only numeric.


Just because you CAN do something does not mean it is a good idea. The whole concept of this is going to be nothing but a complete and total PITA. All kinds of hoops to create the keys, concurrency is a serious concern when you have a table to hold your keys. This thing can and will backfire at some point. It all comes back to what is the gain here?

Sean

I agree that using such an artificial "key" would be a horrible idea and didn't mean to imply that such values should be part of a primary key. But I can see where a computed column approach to create something like an ascending aphanumeric code BASED on an identity value might be useful as part of an employee ID, badge number, or whatever.

Not too many months ago I had a requirement to generate unique registration codes to be handed out to users who would use the code to validate their login. This was a "use-once" code so that the user could login once. The site admins wanted the codes to be sequential because they thought it would be easier for them to administer the codes. I pointed out that if the codes were sequential, anyone with a brain could figure out the sequence from the one authorized code they were given and screw things up. Not to mention the aforementioned difficulties of even doing this as this thread demonstrates. So wisely they took my advice to use random codes.

Now I understand that SQL2012 has a sequential alphanumeric function of some sort, though I haven't seen or tried it yet. So I guess as we all eventually upgrade over the next few years the point will be moot.

Steve

 


I didn't mean to imply that you thought it was a good idea. My apologies. I was simply restating what has been said through this thread in a last attempt at convincing the OP to change their mind. I agree that it could be useful as some sort of code. It would be difficult to maintain though.

I am not familiar with an alphanumeric sequence in 2012. It seems like it would be difficult to establish the rules for how it would work.

There is a sequence but it is numeric.

http://msdn.microsoft.com/en-us/library/ff878058.aspx


_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Post #1467801
Posted Wednesday, June 26, 2013 1:33 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Sunday, September 29, 2013 1:24 AM
Points: 429, Visits: 1,721
Here's the article that I saw lately. I've only skimmed through it but it looks to do the sort of ordering we've been talking about. Looks interesting.

SQL2012 Varchar Sequences

 

 
Post #1467844
Posted Wednesday, June 26, 2013 1:51 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 3:28 PM
Points: 13,103, Visits: 11,933
Steven Willis (6/26/2013)
Here's the article that I saw lately. I've only skimmed through it but it looks to do the sort of ordering we've been talking about. Looks interesting.

SQL2012 Varchar Sequences

 

 


That is interesting. I don't think however it does quite what the OP is trying to do. You will notice in the example code here:


ADD CONSTRAINT Const_Sample_Seq
DEFAULT FORMAT((NEXT VALUE FOR dbo.Sample_Seq),'CUS0000#') FOR [ID];


This is simply converting the numeric sequence to a varchar and appending the hardcoded "CUS0000" in front of the number. The character portion of this is static, and it is the hard part of using an "incrementing" alphanumeric. I don't see anywhere in this example of doing things like A1, A23, B4, etc.


_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Post #1467853
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse