Viewing 15 posts - 57,751 through 57,765 (of 59,067 total)
| Update B : It is a base table problem. I'm still using your code above though. Very useful. ... |
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2006 at 1:02 pm
X/2 records is the difference ![]()
Not sure why Mark thinks one is necessary here even with his latest explanation. Still trying to figure it...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2006 at 12:58 pm
I guess I don't have enough information... first, I'm not sure why you need this...
join Number_list n
on n.number < t.Person_count --This makes a triangular join!!!
WHERE n.number < @Max_person_count
Second, are...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2006 at 11:55 am
Richard,
Each instance of CASE must have an END... You have 3 instances of CASE but only 1 END. That would be the problem.
However, the other guys are right... in this...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2006 at 11:00 am
Here's one way... nasty fast... takes 60-123 milliseconds for 11,000 rows (more than 30 years worth of dates if needed) and 5.8 to 9.2 seconds for a million rows (if TempDB doesn't need to...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2006 at 10:53 am
You bet. Tuan... thank you for the feedback...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2006 at 10:02 am
Thanks Trystan,
Looking back at it, one of the CASE statements is simply overkill... replacing this part should also work with a tiny bit more speed...
--===== Determine the rest...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2006 at 9:21 am
You bet, Ramesh... thank you for the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2006 at 8:41 am
I don't know what I'm missing on this for you... I'll check with my network guys on Tuesday. Sorry I wasn't able to help you without getting help myself --Jeff Moden Change is inevitable... Change for the better is not.
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
September 4, 2006 at 8:39 am
I agree...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2006 at 11:54 pm
Steve... just in case you are interested...
http://www.sqlservercentral.com/community/reviews.asp
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2006 at 9:58 pm
Just a bit of clarification... I've not tested WHERE NOT IN vs OUTER WHERE NULL on sp4... I've seen several differences in execution plans between sp3a and sp4...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2006 at 9:41 pm
It would usually be someone who has a role of "Domain Admin" (I think that's what they call it but not sure... I'm not a network type of guy).
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2006 at 9:38 pm
WHERE IN is not normally an acceptable substitute for a good old fashioned inner join or equi join and tends to be a bit slower. WHERE NOT IN, however, has...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2006 at 9:36 pm
| While Steve's post may have been pushing the boundaries a little Jeff, I still appreciate his response. |
If you're...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2006 at 8:26 pm
Viewing 15 posts - 57,751 through 57,765 (of 59,067 total)