November 24, 2009 at 8:46 am
Using that format, you're lowering your pool to 16 from 36, which only gives you a total 16,777,216 possible permutations and increases your rate of failure over what was originally being tested.
You still haven't explained why you need to use only 6 characters rather than just sticking with newid() and letting the database enforce uniqueness.
November 24, 2009 at 4:07 pm
DECLARE @Codes TABLE(
Code binary(1) PRIMARY KEY
)
INSERT INTO @Codes (Code)
SELECT CONVERT(binary(1), number)
FROM master.dbo.spt_values
WHERE Type = 'P'
AND (number between 65 and 90 OR CHAR(number) LIKE '[0-9]')
SELECT
T1.Code + T2.Code + T3.Code + T4.Code + T5.Code + T6.Code BinaryString,
CHAR(T1.Code) + CHAR(T2.Code) + CHAR(T3.Code) + CHAR(T4.Code) + CHAR(T5.Code) + CHAR(T6.Code) CharString
FROM (select TOP 1 Code from @Codes order by NEWID()) T1
CROSS JOIN (select TOP 1 Code from @Codes order by NEWID()) T2
CROSS JOIN (select TOP 1 Code from @Codes order by NEWID()) T3
CROSS JOIN (select TOP 1 Code from @Codes order by NEWID()) T4
CROSS JOIN (select TOP 1 Code from @Codes order by NEWID()) T5
CROSS JOIN (select TOP 1 Code from @Codes order by NEWID()) T6
Table @Codes may be made permanent to avoid populating it every time.
_____________
Code for TallyGenerator
November 24, 2009 at 4:30 pm
Garadin (11/24/2009)
Using that format, you're lowering your pool to 16 from 36, which only gives you a total 16,777,216 possible permutations and increases your rate of failure over what was originally being tested.You still haven't explained why you need to use only 6 characters rather than just sticking with newid() and letting the database enforce uniqueness.
Heh... probably passwords with some misconception that everyone needs a unique password.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 3 posts - 31 through 33 (of 33 total)
You must be logged in to reply to this topic. Login to reply