Viewing 15 posts - 57,781 through 57,795 (of 59,101 total)
Bingo!!
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2006 at 3:44 pm
Yep... and you've nailed the key to it... exclusive access... now, what table(s) will a developer ALWAYS have exclusive access to?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2006 at 3:32 pm
Yap... we've all written "those"... see the update I just posted to my previous message...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2006 at 3:23 pm
Sure, Remi... thanks for the interest...
Personally, I think triangular joins should never be used because it's an absolutely insane form of RBAR (a "Modenism" for "Row By Agonizing Row"). Here's an example...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2006 at 3:09 pm
| 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
Viewing 15 posts - 57,781 through 57,795 (of 59,101 total)