Viewing 15 posts - 57,286 through 57,300 (of 59,101 total)
Folks, go back and read Vladan's post... that's the only correct way to do it. He explains "why" quite nicely, too.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2006 at 10:59 pm
Careful... that, too, will likely cause a table scan because the column in the WHERE clause is contained in a formula...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2006 at 10:57 pm
Well, when folks post such detailed information about how their code works (very nice job, by the way), others take the code and just use it instead of analyzing it. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2006 at 10:43 pm
Sure, that's what he said he thought the logic should be... he said immediately after that...
"Is the logic correct? Can someone please help me decipher...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2006 at 10:29 pm
Thought this was what he asked for...
"certain action items need to be automatically assigned (through code) a due date on 3 Wednesday’s from whatever today is. "
I agree, the 14...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2006 at 10:23 pm
...except, it doesn't work... if today is the 10th of November, 2006, the 3rd Wednesday from today is on the 29th of November... not the 6th of December...
SET...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2006 at 10:14 pm
Here's an example I made for the boys at work... the Customer Table has about 1.2 million rows in it... page "0" (page 1) will return in about 16 milliseconds. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2006 at 9:50 pm
Len, the following will prevent an index from being used if one is available...
where convert( varchar(10), DateField,112 ) between @T1 and @T2
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2006 at 9:34 pm
Papillon,
Would you post the query that makes the output, please... there may be a trick or two we can pull off on this one...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2006 at 9:27 pm
Do you have an example?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2006 at 6:11 pm
And, be aware that because the code uses a global temp table, you should do something to guarantee that only one instance of the code will ever be executed at...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2006 at 6:10 pm
Robert,
Shifting gears a bit, how's the performance of inserts of new records? How about for a returning customer with a new order? Your clusterd index is VERY contrary to the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2006 at 6:05 pm
Nope... other than moving the table as Serqiy suggested (and, is actually the correct way to do it!), the only other way is by trigger...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2006 at 5:43 pm
I'm assuming that the proc you made from my code example creates a temp table within it... that won't work because of the scope of temp tables... you have to...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2006 at 6:16 am
Gail,
Sorry I don't have time to modify this code snippet I borrowed from some of the production code I wrote for work... lemme give you a couple of hints...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 8, 2006 at 11:29 pm
Viewing 15 posts - 57,286 through 57,300 (of 59,101 total)