It's not just cursors... single row process loops are the real culprit.  Cursors inherently are single row and they use loops.  The real rule is that RBAR (pronounced "ree-bar" and...

Faster than COUNT(*)?

And, here's a simple script for calculating the number of Weekdays between two given dates.  Does not include exclusions for holidays... you would need a holiday table for that.

http://www.sqlservercentral.com/columnists/jmoden/calculatingworkdays.asp

Why do you have the pipe [|] character as the terminator?  You don't have that in the sample data.

Also, are you intending that...

Yep... gotta agree... That's pretty much the reason for NOT storing dates as VARCHAR...  

I think you'll find that WHERE IN has the exact same execution plan and performance as good and proper joins.  I don't like them just because the code comes out...

Heh... yeah, I know... thanks for the reminder to post the results (it's true, I forget a lot)... you're lazy and I'm forgetful... we make a hell of a team...

Try sub-ing this into the code... orginal line says

[Parent] c ON b.facilityID = c.facilityID and b.firstname<>c.firstname

... try changing to ...

 [Parent] c ON b.facilityID = c.facilityID and b.firstname< c.firstname

LMAO!!!  Thanks guys... you were right and I corrected the entry.

Heh... gettin' lazy in your old age, Remi   All times in milliseconds to return 999015 rows in the grid mode of Query Analyzer...

5941...

They tried to kill FoxPro... look what happened there...   And, why does everyone think that Web Apps are a panacea?

Actually, NOT IN and NOT EXISTS create identical execution plans and both are a touch more effecient than an outer join with null detection... as always, here's the proof...

August 11, 2007 at 9:08 pm