Viewing 15 posts - 55,411 through 55,425 (of 59,098 total)
Just remember there, "new poster".... no one called you a "Douche Bag" or "Jive Turkey"... you did. Suggest you make a little bit of a change, yourself.... even in the...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 13, 2007 at 11:54 am
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...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 13, 2007 at 11:10 am
Faster than COUNT(*)?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 13, 2007 at 11:05 am
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
--Jeff Moden
Change is inevitable... Change for the better is not.
August 13, 2007 at 11:03 am
Why do you have the pipe [|] character as the terminator? You don't have that in the sample data. ![]()
Also, are you intending that...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 13, 2007 at 10:56 am
Yep... gotta agree... That's pretty much the reason for NOT storing dates as VARCHAR...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2007 at 4:11 pm
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...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2007 at 10:01 am
| And I always thought EXCEPT is better than NOT IN or NOT EXISTS or LEFT OUTER JOIN |
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2007 at 9:53 am
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...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2007 at 9:43 am
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
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2007 at 9:28 am
LMAO!!! Thanks guys... you were right and I corrected the entry. ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2007 at 9:23 am
Heh... gettin' lazy in your old age, Remi
All times in milliseconds to return 999015 rows in the grid mode of Query Analyzer...
5941...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 11, 2007 at 11:54 pm
They tried to kill FoxPro... look what happened there...
And, why does everyone think that Web Apps are a panacea? ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
August 11, 2007 at 9:13 pm
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...
--Jeff Moden
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.
Change is inevitable... Change for the better is not.
August 11, 2007 at 9:08 pm
Jim,
What is the work assignment that says you must use IN? The reason I ask is that it's a strange assignment and, as others have mentioned, is generally a bad...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 11, 2007 at 8:48 pm
Viewing 15 posts - 55,411 through 55,425 (of 59,098 total)