Viewing 15 posts - 58,606 through 58,620 (of 59,091 total)
Vladan,
My most sincere appologies as well... I thought you were directing it at me... Phil's correct... it's been a terrible week never mind day alone. But that's no excuse and...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2005 at 11:50 am
Not my restrictions but the I agree with your smart-assed comment and useless comment... the client is insane especially in light of the fact that I have a solution that...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2005 at 8:21 am
You bet, Chhana. Simple is good. Thank you for the feed back.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2005 at 2:17 am
Phil,
I sure wouldn't mind seeing that DLL if I can call it as an extended stored procedure. I hadn't thought about that. From a Data Troll aspect, I wouldn't mind...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2005 at 2:00 am
CREATE TABLE myTable
(
myCol BIGINT IDENTITY(1,1),
Col1....
.... other column data
....
)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 28, 2005 at 11:39 pm
Harley,
First, welcome aboard. Thanks for the feedback and you are absolutely correct... it's supposed to add a month and I fat fingered it... I've corrected the problem in the previous...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 28, 2005 at 11:32 pm
Midan1,
YOU WROTE:
----------------------------------------------------------------------------------------but i need to search between dates
like this i can not !!!
SELECT DATEADD(mm,DATEDIFF(mm,0,GETDATE()),0)
, DATEADD(mm,DATEDIFF(mm,-1,GETDATE()),0)
i need to search from
first day of the month
the-1
and between
last
28
--Jeff Moden
Change is inevitable... Change for the better is not.
November 25, 2005 at 1:15 pm
Instead of messing around with milliseconds and adding 31 days, etc.... it's a takeoff on what the other posters have done but a wee bit different... works kinda like Frank's...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2005 at 1:42 am
Can do...
SELECT FieldID,
MIN(CASE WHEN FieldName = 'NAME' THEN FieldValue END) AS NAME,
MIN(CASE WHEN FieldName = 'Address' THEN FieldValue END) AS Address,
MIN(CASE WHEN FieldName = 'ZIP' ...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2005 at 1:31 am
One more thing! Don't even think of using the SELECT/INTO/RENAME method if others are updating the table at the same time or inserting new rows.... YOU WILL LOSE...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2005 at 10:51 am
Almost forgot... does the table being updated have any triggers? That really make things slow for this big an update especially if those triggers are writing to audit tables or...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2005 at 10:41 am
Yup, I'd lose the OUTER JOIN if an INNER JOIN will do. Also, like someone else asked, "What is slow"? I normally shoot for about 500,000 rows per minute (sometimes...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2005 at 10:38 am
Very, very cool... ol' Itzik did a neat job on this one.
Ken, do you know of a fn_DecToBase function in a similar vein by anyone?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 19, 2005 at 7:51 am
Get the list of database names from Master.dbo.SysDataBases... build your own loop or (yeeach!) cursor to step the the DB names or ID's as the outer nest for sp_MSForEachTable.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 19, 2005 at 7:07 am
Brilliant use of recursion guys! Absolutely awesome.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 18, 2005 at 7:38 pm
Viewing 15 posts - 58,606 through 58,620 (of 59,091 total)