Viewing 15 posts - 51,226 through 51,240 (of 59,098 total)
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
Forgive me for doing just a quick scan of the threads... couldn't you use the Information_Schema views for this?
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2008 at 8:46 pm
Um.... if it's not a 3rd party application, check the "Model" database... sp_MSrepl_PAL_rolecheck is a sproc from the Master database and shouldn't exist anywhere else.
Compare what's in the sp_MSrepl_PAL_rolecheck sproc...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2008 at 8:41 pm
pauls2 (4/7/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2008 at 8:27 pm
mrpolecat (4/7/2008)
build your numbers table ( I call mine tally because Jeff Moden does:D.
Now, there's a heck of a compliment. 😀 Thanks, MrPoleCat!
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2008 at 8:22 pm
Grant Fritchey (4/7/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2008 at 8:14 pm
Uh, huh... several different ways in the following URL along with some performance pit-falls to avoid...
http://www.sqlservercentral.com/articles/Test+Data/61572/
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2008 at 8:02 pm
It would be an aggregate query to sum all the CDRs (Call Detail Records for Telephone Billing) for a about 120 thousand customers in a 4-5 million row table. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2008 at 7:57 pm
Steve Jones - Editor (4/7/2008)
Yikes!Just put it in the Version Control script for database creation 🙂
Hi Steve,
As with Matt, I always appreciate it when you jump in on one of...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2008 at 6:13 pm
Viewing 15 posts - 51,226 through 51,240 (of 59,098 total)