Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Get a range of numbers


Get a range of numbers

Author
Message
diaz.bernabe
diaz.bernabe
Old Hand
Old Hand (319 reputation)Old Hand (319 reputation)Old Hand (319 reputation)Old Hand (319 reputation)Old Hand (319 reputation)Old Hand (319 reputation)Old Hand (319 reputation)Old Hand (319 reputation)

Group: General Forum Members
Points: 319 Visits: 194
Comments posted to this topic are about the item Get a range of numbers
MVDBA
MVDBA
SSCrazy
SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)

Group: General Forum Members
Points: 2515 Visits: 860
wouldn't this be easier to do with a recursive CTE?


declare @start bigint=99;
declare @end bigint=147;
with x (num) as
(
select @start as num
UNION ALL
SELECT num+1 from x
where num <@end
)
select * from x where num between @start and @end
option (maxrecursion 10000);

MVDBA
Cadavre
Cadavre
SSCrazy
SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)

Group: General Forum Members
Points: 2852 Visits: 8445
michael vessey (5/2/2012)
wouldn't this be easier to do with a recursive CTE?


declare @start bigint=99;
declare @end bigint=147;
with x (num) as
(
select 1 as num
UNION ALL
SELECT num+1 from x
where num <@end
)
select * from x where num between @start and @end
option (maxrecursion 10000);


Or . . .
DECLARE @start BIGINT = 97;
DECLARE @end BIGINT = 250000;

WITH CTE(n) AS(SELECT 1 UNION ALL SELECT 1),
CTE2(n) AS (SELECT 1 FROM CTE x, CTE y),
CTE3(n) AS (SELECT 1 FROM CTE2 x, CTE2 y),
CTE4(n) AS (SELECT 1 FROM CTE3 x, CTE3 y),
CTE5(n) AS (SELECT 1 FROM CTE4 x, CTE4 y),
CTE6(n) AS (SELECT 0 UNION ALL
SELECT TOP (@end-@start)
ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM CTE5 x, CTE5 y)
SELECT @start+n
FROM CTE6
WHERE @start+n <= @end;



Or. . .
DECLARE @start BIGINT = 97;
DECLARE @end BIGINT = 1000000;

SELECT @start+n
FROM (SELECT 0 UNION ALL
SELECT TOP (@end-@start)
ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM master.sys.columns a, master.sys.columns b, master.sys.columns c) a(n)
WHERE @start+n <= @end;




Forever trying to learn

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better, quicker answers on SQL Server performance related questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/



If you litter your database queries with nolock query hints, are you aware of the side effects?
Try reading a few of these links...

(*) Missing rows with nolock
(*) Allocation order scans with nolock
(*) Consistency issues with nolock
(*) Transient Corruption Errors in SQL Server error log caused by nolock
(*) Dirty reads, read errors, reading rows twice and missing rows with nolock


Craig Wilkinson - Software Engineer
LinkedIn
MVDBA
MVDBA
SSCrazy
SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)

Group: General Forum Members
Points: 2515 Visits: 860
depends if you need a BIGINT or not - i'd suggest just using yours for anything when max-min > 32,767 - otherwise use the nice small (low resource) version

MVDBA
Cadavre
Cadavre
SSCrazy
SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)

Group: General Forum Members
Points: 2852 Visits: 8445
michael vessey (5/2/2012)
depends if you need a BIGINT or not - i'd suggest just using yours for anything when max-min > 32,767 - otherwise use the nice small (low resource) version


Actually, you should pretty much never use recursive CTEs for counting. See this article for why.


Forever trying to learn

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better, quicker answers on SQL Server performance related questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/



If you litter your database queries with nolock query hints, are you aware of the side effects?
Try reading a few of these links...

(*) Missing rows with nolock
(*) Allocation order scans with nolock
(*) Consistency issues with nolock
(*) Transient Corruption Errors in SQL Server error log caused by nolock
(*) Dirty reads, read errors, reading rows twice and missing rows with nolock


Craig Wilkinson - Software Engineer
LinkedIn
MVDBA
MVDBA
SSCrazy
SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)

Group: General Forum Members
Points: 2515 Visits: 860
Cadavre (5/2/2012)
michael vessey (5/2/2012)
depends if you need a BIGINT or not - i'd suggest just using yours for anything when max-min > 32,767 - otherwise use the nice small (low resource) version


Actually, you should pretty much never use recursive CTEs for counting. See this article for why.



run the CTE and the cross join version you posted and look at the execution plans.... then see the difference

the CTE has it's place when dealing with small numbers

MVDBA
Cadavre
Cadavre
SSCrazy
SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)

Group: General Forum Members
Points: 2852 Visits: 8445
michael vessey (5/2/2012)
Cadavre (5/2/2012)
michael vessey (5/2/2012)
depends if you need a BIGINT or not - i'd suggest just using yours for anything when max-min > 32,767 - otherwise use the nice small (low resource) version


Actually, you should pretty much never use recursive CTEs for counting. See this article for why.



run the CTE and the cross join version you posted and look at the execution plans.... then see the difference

the CTE has it's place when dealing with small numbers


Did you have a gander at Jeff Moden's article that I linked? --> http://www.sqlservercentral.com/articles/T-SQL/74118/


Forever trying to learn

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better, quicker answers on SQL Server performance related questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/



If you litter your database queries with nolock query hints, are you aware of the side effects?
Try reading a few of these links...

(*) Missing rows with nolock
(*) Allocation order scans with nolock
(*) Consistency issues with nolock
(*) Transient Corruption Errors in SQL Server error log caused by nolock
(*) Dirty reads, read errors, reading rows twice and missing rows with nolock


Craig Wilkinson - Software Engineer
LinkedIn
Gullimeel
Gullimeel
SSC Veteran
SSC Veteran (247 reputation)SSC Veteran (247 reputation)SSC Veteran (247 reputation)SSC Veteran (247 reputation)SSC Veteran (247 reputation)SSC Veteran (247 reputation)SSC Veteran (247 reputation)SSC Veteran (247 reputation)

Group: General Forum Members
Points: 247 Visits: 506
Using a table with numbers is best way

GulliMeel

Finding top n Worst Performing queries
Improve the performance of Merge Join(special case)
How to Post Performance Problem -Gail Shaw
Tee Time
Tee Time
SSChasing Mays
SSChasing Mays (603 reputation)SSChasing Mays (603 reputation)SSChasing Mays (603 reputation)SSChasing Mays (603 reputation)SSChasing Mays (603 reputation)SSChasing Mays (603 reputation)SSChasing Mays (603 reputation)SSChasing Mays (603 reputation)

Group: General Forum Members
Points: 603 Visits: 465
This may be only slightly related, but thought I'd share.

I used this solution for creating sequential carton labels for shipping.

I created a procedure that populates a table of sequential numbers by feeding in parameters from a SSRS report. In this case I feed the beginning and ending number.

CREATE PROCEDURE SEQUENTIAL
(
@BEG_NUM INT,
@END_NUM INT
)
AS

DECLARE @start INT
DECLARE @end INT

SELECT @start = @BEG_NUM, @end = @END_NUM

WHILE @start <= @end
begin
INSERT INTO BUR20VM.dbo.SEQUENTIAL_TABLE(CTN_NUM_SEQ)
VALUES(@start)
SET @start = @start + 1
END
GO

I then use the resulting table results in a cross join with another table, to get the label output.

I should also note, when I go to run the next sequence of numbers (for the next shipment), the SSRS report first EXECutes a second stored procedure to delete all values from the previosly created SEQUENTIAL_TABLE, and then re-populates with the new sequence of numbers.

I think this is a good illustration of a real world application for the sequential table. :-)
Iwas Bornready
Iwas Bornready
SSCrazy Eights
SSCrazy Eights (9.8K reputation)SSCrazy Eights (9.8K reputation)SSCrazy Eights (9.8K reputation)SSCrazy Eights (9.8K reputation)SSCrazy Eights (9.8K reputation)SSCrazy Eights (9.8K reputation)SSCrazy Eights (9.8K reputation)SSCrazy Eights (9.8K reputation)

Group: General Forum Members
Points: 9774 Visits: 885
Thanks for the script.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search