Viewing 15 posts - 34,321 through 34,335 (of 59,099 total)
Shifting gears real hard, I'm finally done not only testing a fix to the Tally Table delimited string splitter performance problem, but I've also finished the article on it. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2011 at 11:56 pm
I think you'll actually have a difficult time keeping it down to only an hour. As the others have said, the only way to know is to deliver the...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2011 at 11:50 pm
sturner (4/7/2011)
I have appreciated many of your excellent posts over that...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2011 at 1:10 am
ranjodh_makkar (4/7/2011)
--Now move data to temp table by writting a function which return all the the dates and insert data in this ##result table and Insert/Update data accordingly
I don't recommend...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2011 at 1:04 am
Here's the non-Quirky Update code to do what you want. For those that think a CTE would be better, please read the comments in the code to find out...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2011 at 8:50 pm
Also, be advised. You didn't add the required clustered index to the #Temp table and that may be why your 2 part code didn't work the way you expected....
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2011 at 8:27 pm
Nadrek (4/8/2011)
Thank you for your response; I'll see if I get the chance to generate sample data and schemas, as well as the two-part SET statement variant.
Nadrek,
Considering that you're only...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2011 at 8:20 pm
vilonel (4/8/2011)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2011 at 7:25 pm
Thanks for the kudo, Jeremy. :blush: I really appreciate it. And thanks for helping me find one of my "lost posts". I've been looking for this...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2011 at 7:18 pm
BWAA-HAA!!! I guess I should be really insulted by some of the comments you have in the code.
-- This is an UNRELIABLE METHOD of doing business (Quirky...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2011 at 6:54 pm
MyDoggieJessie (4/8/2011)
WHERE ([NextDateTime] between CONVERT(DATETIME,(CONVERT(VARCHAR(10),getdate(),121) + ' 00:00:00.000'))
and CONVERT(DATETIME,(CONVERT(VARCHAR(10),getdate(),121) + ' 23:59:59.999'))) and [Disabled] = 0
What they are trying to do is...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2011 at 6:28 pm
MyDoggieJessie (4/8/2011)
But wouldn't that defeat the purpose of getting a date like "2011-04-08 00:00:00.000" in the first place?
SELECT DATEADD(dd,0,GETDATE()) results in "2011-04-08 09:17:05.080"[/code]
I never suggested that code or...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2011 at 6:15 pm
... or not. I've found that sometimes it's more important to prevent parameter sniffing by letting it go ahead and recompile. "It Depends". 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2011 at 6:13 pm
The reason I was asking is that if you had special characters such as < or >, etc, then we'd have to add just a little more code (which also...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2011 at 6:10 pm
BWAA-HAAA!!! Maybe it's not a "stump" after all. Thinking back, I've always joined the tables that will return the smallest result set first so maybe I've seen it...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2011 at 8:11 am
Viewing 15 posts - 34,321 through 34,335 (of 59,099 total)