November 28, 2003 at 12:00 am
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/glarsen/sequentialnumbering.asp
Gregory A. Larsen, MVP
December 6, 2003 at 3:25 pm
Some good techniques if you really need to do this in SQL, but my argument often for this process is to have the client do it. VB, Crystal, ASP, etc. all process the rows sequentially and it is very easy and much less resource intensive to have the client calculate the sequential numbers.
Steve Jones
http://www.sqlservercentral.com/columnists/sjones
The Best of SQL Server Central.com 2002 - http://www.sqlservercentral.com/bestof/
December 8, 2003 at 8:01 am
I whole heartly agree with the client side solution when ever possible.
Gregory A. Larsen, DBA
Contributor to 'The Best of SQLServerCentral.com 2002' book. Get a copy here: http:www.sqlservercentral.com/bestof/purchase.asp
Need SQL Server Examples check out my website at http://www.geocities.com/sqlserverexamples
Gregory A. Larsen, MVP
December 8, 2003 at 3:46 pm
Another way to do this is using Indentity, not using it as a property of a column, but as function in a TSQL statement. Using your example:
select Identity(int,1,1) as rank, Hiredate, LastName, Firstname
into #hireDate
from northwind.dbo.employees
where Title = 'Sales Representative'
order by HireDate
Select cast(rank as char(4)) as Rank,
cast(hiredate as varchar(23)) as HireDate,
LastName,
FirstName from #HireDate order by 1
Drop table #HireDate
I think this could be a good function to have in mind, specially when you want a quickly solution.
Roberto Figueroa
figaroATgcmexDOTcom
May 3, 2004 at 5:44 am
Just a note... The IDENTITY function can only be used when the INTO clause (as Figaro did) is also present or you will get the following error...
Server: Msg 177, Level 15, State 1, Line 1
The IDENTITY function can only be used when the SELECT statement has an INTO clause.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2004 at 2:35 am
There is another technique. Gert Drapers did a straw poll of the audience at one of his PASS presentations this year to see who knew about this technique and very few did...hence its probably worth passing on here.
Stick the following into QA and run:
--I have a table:
USE tempdb
GO
CREATE TABLE MyTable (
MyTableID int NULL,
[Name] varchar(35) NOT NULL
)
--I populate some data
INSERT MyTable ([Name]) VALUES ('Jamie')
INSERT MyTable ([Name]) VALUES ('David')
INSERT MyTable ([Name]) VALUES ('Harold')
GO
--I then run the following to populate MyTableID
DECLARE @vKeyCounter int
SET @vKeyCounter = (SELECT ISNULL(MAX(MyTableID), 0) FROM MyTable)
UPDATE MyTable
SET @vKeyCounter = MyTableID= @vKeyCounter + 1
WHERE MyTableID IS NULL
OPTION (MAXDOP 1)
--View the results
SELECT *
FROM MyTable
The clever bit is the SET part of the UPDATE statement which also changes the variable @vKeyCounter.
Have a go with this and let me know what you think. I'd appreciate feedback.
Jamie Thomson
http://sqlblog.com/blogs/jamie_thomson
December 7, 2004 at 2:39 am
I've just realised that this thread is over a year old. I hope someone reads it!!!
There was a link to it in the 2004-12-06 newsletter which is why I happen to be replying to it now!
Jamie Thomson
http://sqlblog.com/blogs/jamie_thomson
November 28, 2006 at 7:51 am
Jamie --
I like the approach because of its simplicity; however, if the records are numbered in the order that they appear in the table. This may be good approach if coupled with a temporary table built on some select statement (in a SP for example) so that the records are ordered before the sequential number is applied for some display purpose.
Art
DOH! I just noticed that your comment was two years old.
November 28, 2006 at 9:30 am
Heh... better late than never...
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply