Viewing 15 posts - 51,676 through 51,690 (of 59,091 total)
I agree with the others... find and fix the problem... and, Know this... Setting the Transaction Isolation Level and using WITH (NOLOCK) is NOT a panacea for fixing deadlocks.
We were...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 12:44 pm
Sorry... forgot to add the line that makes it more than twice as fast...
DECLARE @Year INT
SET @Year = 2008
;WITH cteDates AS
(
SELECT DATEADD(yy,@Year-1900,0)+Number AS TheDate
...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 12:32 pm
Matt is absolutely spot on. Without actually getting into using a Tally table to do this, here's one way to programmatically generate a Year's worth of dates using a...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 12:20 pm
Just my 2 cents... I'm always pretty much amazed at such requests... I do one of two things in most cases where someone "has to have it" in an Excel...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 12:05 pm
In other words, Dragon3486... messy code is hard to troubleshoot. 95% of all such simple syntactical problems can easily be avoided altogether if you format your code in an...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 11:55 am
More likely, since you said you had the window open for days, the data in the tables the view references changed. Doesn't take a lot... if your execution plan...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 11:50 am
And, the "re-used" execution plan for 1 set of parameters might be absolutely terrible with another set or sometimes a thing called "parameter sniffing" kicks in and the whole server...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 11:46 am
If, what you really mean, is that you don't want anyone to be able to "steal" your code, then you must check all of your code into some safe place...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 11:40 am
swathichilukuri85 (3/18/2008)
thank u jeffcan u provide me the script
The others are correct... We can't write a script for your tables because you haven't posted them or any sample data....
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 11:32 am
Both are nothing more than "in-line" views... views can use indexes just like any query can. Same goes for CTE's and Derived tables... "Have Index, Will Compute". 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 11:20 am
I've had a great many similar experiences especially with poor performance due to Table Variable usage. If you add in the fact that TempTables persist in Query Analyzer whereas...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 10:58 am
If you really want technical... scroll back up to the early stages of this thread and look at the URL I recommended... :hehe:
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 10:25 am
srienstr (3/18/2008)
I'll stick to indexed temp tables for self-links then. (The base table used in this process has around 300k rows)
If the underlying tables are correctly indexed, the CTE...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 10:22 am
But I want my Easter Eggs NOW!!! Where's my porkchops? 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 8:45 am
Tao Klerks (3/18/2008)
I don't think I agree about the clarity of using CTEs for derived tables, but I guess that might be...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 8:37 am
Viewing 15 posts - 51,676 through 51,690 (of 59,091 total)