Viewing 15 posts - 50,416 through 50,430 (of 59,099 total)
I'm pretty sure indexing won't do much good on this because of all the formulas in the join and the Row_Number partition/order by.
Why must it be ordered by the LEN?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 6:38 pm
Setup profiler to page, call, email, and throw rocks at the hardware team everytime a query takes longer than a certain time to execute... you sleep. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 6:33 pm
If you're going to do it more than once in the same proc, make a temp table and join to it because IN, OR, and INNER JOIN are pretty much...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 6:25 pm
You used a colon instead of a semi-colon... "Must look eye" 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 6:19 pm
GSquared (5/20/2008)
If you don't have a Numbers table, now's a good time to build one (it's easy). It will help with this problem.
... and here's how to build/use one...
http://www.sqlservercentral.com/articles/TSQL/62867/
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 6:16 pm
Slawek (5/20/2008)
Well, if you convince me that fixing indexes will improve SAN performance, then I'll drop all my tests with multiple files and start fixing indexes 🙂
My problem is that...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 6:13 pm
Please... see the URL in my signature...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 5:55 pm
First, not enough data... without an extra column (hopefully, a PK) to identify the sort order, there's no way to do an update because SQL Server will not know which...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 5:54 pm
jcrawf02 (5/20/2008)
In case anyone else wants to use Jeff's example and is lazy like me:copy/save as a template (.tql) under C:\Program Files\Microsoft SQL Server\80\Tools\Templates\SQL Query Analyzer--------------------------------------------------------------------
Sigh... if only everyone were...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 5:47 pm
JohnG (2/22/2008)
What we also need to eliminate are:
1. The postings where the poster didn't even bother to look at the online documentation (Books Online aka BOL)...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 5:45 pm
J (2/1/2008)
And I also liked the bit on the CSV generator.
Just gotta have more than 1 tip per article... thanks for the feedback, J.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 5:43 pm
Table_A should have the clustered index on the ID column for the tables you have shown. Otherwise, not enough info...
Write the query you want and tune it by looking...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 5:36 pm
I test all code I post so the answer is, "YES", the code is correct. Please post the error you are getting.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 5:33 pm
Same goes in 2000... in fact, our standards recommend trying the WHERE NOT IN before trying the OUTER JOIN fore exclusions of this nature.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 5:31 pm
Or, you can go straight in...
[font="Courier New"]DECLARE @SomeDate VARCHAR(20)
SET @SomeDate = '19-05-2008 09:46:35 AM'
SELECT CONVERT(VARCHAR(20),CONVERT(DATETIME,@SomeDate,105),126)+'.00Z'[/font]
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 5:24 pm
Viewing 15 posts - 50,416 through 50,430 (of 59,099 total)