Viewing 15 posts - 58,606 through 58,620 (of 59,063 total)
Brian,
David is on the right track with a function but, here's some simpler code that uses classic "base" conversion techniques... it may be just a bit faster because it's 100%...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 11, 2005 at 7:08 am
SELECT NEWID()
Use substring to get a piece if you want.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2005 at 10:30 pm
Ami,
I didn't take the time to convert this to your table or column names. If you are using INT for your ID's, it's good to 727 levels... usually more than...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2005 at 10:28 pm
First, I'd have to ask why do you need a more definitive answer? The simple truth of the matter is that's the way they made it and none of us...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2005 at 10:11 pm
![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2005 at 10:27 am
Farrell,
You didn't read far enough down where I said "Adam Mechanic would probably remind you about the need for auxilary calendar tables or at least a numbers table...". Or were...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 4, 2005 at 7:54 pm
Dunno about all the DST and GMT stuff, but here's a way to find the last Saturday of a month given any date in that month... since it includes time,...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 2, 2005 at 10:00 pm
This works...
SELECT CAST(YYYY+MM+DD AS SMALLDATETIME)
The reason why it works is because yyyymmdd is one of the (ISO) recognized datetime formats... no need for the slashes or anything...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2005 at 10:30 pm
I can't take the credit for the following but it does the job for me....
"Normalize 'till it hurts... Denormalize 'till it works."
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2005 at 10:27 pm
>This is a presentation issue, hence my second select will give you the output you want, but that is not really a SQL Server job
It depends... if there's no presentation...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2005 at 10:23 pm
As a "best practice", you should always use at least the two part naming convention, which includes the user name. There's dozens of articles on this recommendation on the Web......
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2005 at 10:13 pm
>because DB programming is almost the same in oracle and in sql 2000
Boy oh boy are you in for a surprise! Take, for instance, that SQL Server 2000 has a...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2005 at 9:59 pm
Couldn't see the forest for the circumlocution ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2005 at 9:44 pm
I don't get it, Neetu... you posted...
RefNo Pro_No Country
1. 11,22,33,44 X
2. 33,44,22,11 Y
3. 44,55,33,22 Z
Explain to me why 44 is in RefNo 1, why 33,44 is in RefNo2, and why...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2005 at 9:38 pm
You bet, Henk... thank you for the feed back.
I gotta know... what's comical about it?
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2005 at 5:24 pm
Viewing 15 posts - 58,606 through 58,620 (of 59,063 total)