Viewing 15 posts - 42,061 through 42,075 (of 59,067 total)
ps (8/26/2009)
SELECT DATEADD(s,-1,DATEADD(mm, DATEDIFF(m,0,GETDATE())+1,0)),Case
datepart(dw, DATEADD(s,-1,DATEADD(mm, DATEDIFF(m,0,GETDATE())+1,0)))
When 0 Then 'Sunday'
when 1 then 'Monday'
When 2 then 'Tuesday'
when 3 Then 'Wednesday'
When 4 Then 'Friday'
When 5 Then 'Saturday'
End
as Day
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2009 at 10:01 pm
Going way back to the very first post on this thread, the answer is a resounding [font="Arial Black"]YES![/font]
http://www.sqlservercentral.com/Forums/Topic783201-146-1.aspx?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2009 at 9:44 pm
I wouldn't use DATEPART to get the time... you'd have to use it more than once depending on what the expected return would be.
Of course, we don't actually know what...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2009 at 9:35 pm
Conrats indeed. Well done. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2009 at 7:50 pm
sudhanva (9/4/2009)
Thanks for the huge response and fun here. I didnt expect a 4page posts for this topic 😎
The query which has vendor_id etc was just an example, it...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2009 at 7:33 pm
chris.fauvel (9/4/2009)
"am I all set?"yes/no
since there were only 6 skus like that I just updated them, but I would love to have an elegant solution, that is easy.
Thanks
Chris
Like Seth...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2009 at 9:15 am
Good tip... but because it get's it's info from the same place as sp_SpaceUsed, it also has the same problems as sp_SpaceUsed.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2009 at 5:35 am
David Burrows (9/4/2009)
Jeff Moden (9/3/2009)
.enots ot nrut t'nod I os rorrim a hguorht siht ta gnikool yllautca m'I ...denrawerof neeb d'I 😉
:crazy:
iday eenbay orewarnedfay... imay actuallyay ookinglay atay isthay oughthray...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2009 at 5:28 am
franz.ladda (9/3/2009)
MERGE INTO unknown_ip ip1
USING (SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2009 at 10:59 pm
Damien (9/3/2009)
Im sorry I did not understand the first one that was suggested to me. I'm starting to read online books regarding trigger....
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2009 at 10:21 pm
GSquared (9/3/2009)
My ethics are more important to me than my paycheck.
Ditto...
I'll also add that my ethics and integrity are the reason why I have a paycheck.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2009 at 10:05 pm
Sudeepta (9/3/2009)
I have come with no programming background.
Although that may make it a bit difficult for you, it may also provide an extreme advantage for you... you have no bad...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2009 at 9:54 pm
I'm probably going against the general grain here but I have a special name for "DBA's" who don't know T-SQL really, really well... "SysOp". My other name for them...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2009 at 9:37 pm
Heh... now I'm really going to tick you off... except when trying to convert from date formats that are in the basic form DD/MM/YYYY when the default date format is...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2009 at 9:11 pm
Damien (9/3/2009)
First Im not allowed to modify the software that can do deletion of data in our SQL server. So...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2009 at 8:47 pm
Viewing 15 posts - 42,061 through 42,075 (of 59,067 total)