Viewing 15 posts - 51,211 through 51,225 (of 59,091 total)
Bob...
Don't need the join at all if only the Attendance table is involved and the join has nothing to do with getting rid of the Temp table. Were inserting...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2008 at 9:06 pm
Wow... lemme say that again... WOW! SQL Server 2005 sucks for this! Yeah... it was a real world example.... In the real world, we have SQL Server...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2008 at 8:57 pm
Matt Miller (4/8/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2008 at 8:05 pm
If you're going to do it that way, Bob, you need to understand that you may have a fundamental flaw in your code... remember the comment in one of your...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2008 at 7:08 pm
Heh... you should compare those with STUFF 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2008 at 6:07 pm
There's a bunch of "sys.All_" views that are "server wide".
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2008 at 6:05 pm
Thanks for the feedback folks. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2008 at 6:00 pm
Sure, you could sub RowNum for *... not sure it matters for performance here as it might in other places. * allows it to pick the best index it...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2008 at 6:30 am
Mike Menser (4/8/2008)
Also, 'SEQUEL' has prevailed over the competition in this instance.
Heh... that's probably why I'll continue to use S-Q-L... 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2008 at 6:19 am
Truncate can be rolled back within an explicit transaction just as Adam said... try it on a table that can easily be rebuilt like a Tally table...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2008 at 10:50 pm
Google for sp_MSForEachTable...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2008 at 10:27 pm
rbarryyoung (4/7/2008)
It was an exciting time, but it's got nothing on today. Seriously, living in the future rocks.
The past "rocks", too... had to use rocks because the Abacus hadn't...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2008 at 9:41 pm
Heh... I gotta agree with that...
Moot point now, though... I just found out that they want to aggregate the aggregates in these views across the databases. Gotta trade in...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2008 at 9:21 pm
Ummm... be very careful using CROSS APPLY... it's just another way of making a "correlated subquery" which qualifies as RBAR and can be very slow.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2008 at 8:51 pm
I'm pretty sure recursion will be a performance killer here... please check out the XML code at the following URL (last bluish/purple code box in the article)...
http://www.sqlservercentral.com/articles/Test+Data/61572/
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2008 at 8:48 pm
Viewing 15 posts - 51,211 through 51,225 (of 59,091 total)