Viewing 15 posts - 41,461 through 41,475 (of 59,102 total)
You shouldn't have to partition anything for a 7k row table because it won't help when returning all rows and columns.
Something is dreadfully wrong if it takes that long to...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 5:37 pm
A "search" on this site is still one of the best ways to find what you need...
When you run across one of the many articles or scripts on this subject,...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 5:32 pm
That will certainly work and if you don't have many rows, you probably won't notice, but REVERSE is comparatively very expensive... it would be computationally cheaper if you just used...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 5:51 am
No problem... just remember that it leaves a trailing comma and does the whole table unless you add a criteria.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 5:44 am
matt6749 (10/19/2009)
Ok thanks Jeff - I am going to try, and try hard, to implement multiple CTEs like you suggest.. (gulp, wish me luck!) - Matt
You'll do fine... just...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 5:40 am
On second thought, since you need the calculated distance as part of the result set, you may want to include the calculated distance in the first CTE which is limited...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 19, 2009 at 11:25 pm
Actually, it's probably not...
In a CTE, create a result set using the "Narrow Horizontal Corridor" formulas we talked about. Then, in another CTE, do the radius calculations on the...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 19, 2009 at 11:19 pm
To be clear, you'll still need to do the radius calculation but the addition of the MAX variables I spoke of should really cut down on the number of complex...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 19, 2009 at 11:12 pm
matt6749 (10/19/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
October 19, 2009 at 11:04 pm
Shairal-763732 (10/19/2009)
Our home office overwrites a table every night with new data. I want to know when a new row appears in the table, but if they...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 19, 2009 at 10:50 pm
mspiegel (10/19/2009)
Bru,I'm not familiar with the Pivot syntax. Could you provide a sample for me?
Thanks!
Yep... same priciple as in the following...
http://www.sqlservercentral.com/articles/T-SQL/63681/
--Jeff Moden
Change is inevitable... Change for the better is not.
October 19, 2009 at 10:46 pm
Heh... don't forget the false physicians. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
October 19, 2009 at 10:42 pm
Heh... at least you're doing SOME testing. A lot of shops that I've done work for generally let the users find the problems for them... we all know how...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 19, 2009 at 10:14 pm
The biggest reason why you're getting a SCAN of any sort instead of a SEEK is because of the forumula itself... it must calculate every zip code to find which...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 19, 2009 at 10:00 pm
WayneS (10/19/2009)
Just had a "developer" send me some code.
SP "a" has...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 19, 2009 at 8:50 pm
Viewing 15 posts - 41,461 through 41,475 (of 59,102 total)