Viewing 15 posts - 49,816 through 49,830 (of 59,102 total)
No, NO, NO!!! Never ever store formatted data! You will pay dearly for doing so someday in the future. This type of (leading zero) formatting should really...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 9:08 pm
giontech (6/21/2008)
I need help in how to get data from a table with a daterange from sunday to saturday of the last week.
What I'm looking for is to be able...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 8:47 pm
Mani Singh (6/21/2008)
you can use this and manipulate this query to code as needed..DECLARE @GENRANDOM nvarchar(9)
SET @GENRANDOM =LEFT(SUBSTRING (RTRIM(RAND()) + SUBSTRING(RTRIM(RAND()),3,11), 3,11),9)
--SELECT SUBSTRING(@GENRANDOM ,3,1)
SELECT @GENRANDOM as 'RANDOM_NUMBER'
Yep... you could do...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 8:05 pm
Here's one way to do it in 2005... The neat thing is it doesn't use any RBAR or a sequence table. You could use UPDATE and OUTPUT to return...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 8:00 pm
ola_blixten (6/17/2008)
My case:
I want to generate 5 digit random numbers which should start with:
00001
00002
00003.....
and 2 digit for week so from 1-52
and 1 digit for year, from 0-9
And everyting should be...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 7:05 pm
Rebuilding the indexes after that might help... 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 6:44 pm
During the repopulation of TableB in DTS, your users will wait.
Why does this have to be DTS? Why can't it be DTS executing a proc?
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 4:13 pm
If temp table contains ALL the final information that original table will have once you do all the inserts and updates to it, why not just "swap" tables?
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 4:07 pm
Ugh... thousands of growths probably also mean thousands of fragments for the database and thousands of fragments for the underlying file. For the same reason that people use defrag...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 3:29 pm
Heh... I'll agree that the author had a naming convention problem with choosing the title of the article... 😉
I've also found that a great many "personal preferences" can really gum...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 2:56 pm
Heh... still, the best thing to do would be to give the person requesting that this be done without adding an IDENTITY column and without using an intermediate table a...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 2:48 pm
Oh, very clever... well done, Barry!
Only corrections are to remove the CASE in the final insert and to delete the compressed rows...
Other than that, very, very clever... 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 2:46 pm
Tally table method in 2000 for this would require a triangular join... I believe. If you know a way to do this in 2k without using a loop but...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 12:53 pm
Jeff Moden (6/21/2008)
Steve Jones - Editor (6/21/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 12:51 pm
rbarryyoung (6/21/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
June 21, 2008 at 12:50 pm
Viewing 15 posts - 49,816 through 49,830 (of 59,102 total)