Viewing 15 posts - 20,071 through 20,085 (of 22,212 total)
It's probably parameter sniffing. As everyone else has already said, get the execution plans and see what the differences are.
June 30, 2008 at 7:54 am
I even had a guy go off on a huge lecture that we were asking too many SQL Server specific questions (for a SQL Server specific position) because we should...
June 30, 2008 at 7:53 am
Hey guys,
I've been out of town. Thanks for keeping the conversation going. Especially since you've been supplying answers much better than the ones I would have supplied.
June 30, 2008 at 6:48 am
Yeah, I have to agree. A blanket statement like that is not good.
June 30, 2008 at 6:31 am
Yes, you want to analyze the trace. A standard trace, using the defaults, will capture the execution time, I/O and CPU costs. That's what you need to look at. It's...
June 30, 2008 at 6:08 am
Be afraid. Be very afraid.
I do the technical interviews for our team. We go through about 20-30 phone screens in order to find someone worth bringing in for an interview....
June 30, 2008 at 6:04 am
One thing not mentioned is the use of copy & paste. We have a project that's actually, honestly, a little complex. In one place, we found we needed a query...
June 30, 2008 at 5:39 am
Jeff Moden (6/24/2008)
jimige257 (6/24/2008)
Is it worth spending 2 hours optimizing a prodedure that works now and is needed last week? Many would say not.
And, THAT is why I tell folks...
June 30, 2008 at 5:34 am
Convert the NOT IN statement to a LEFT JOIN and only select values where the key from the second table are NOT NULL. That's much more likely to make good...
June 24, 2008 at 12:16 pm
You have to issue a USE statement or quantify the object names in the queries with the database name. Neither method supports using a parameter which is why all you'll...
June 24, 2008 at 9:24 am
This will work with 2000:
SELECT
A.RetailerID,
b.RetailerIDTheirs
FROM TableA AS A
LEFT JOIN TableB AS B
ON A.RetailerID =...
June 24, 2008 at 9:22 am
The short and long answer in this case is, it depends.
There are a lot of variables involved in this sort of thing and the right answer in one case isn't...
June 24, 2008 at 8:39 am
Only 62 tables. We had one that was 85 and we got it to run in under 2 seconds (of course, it took 12 minutes to recompile).
But seriously, everyone else...
June 24, 2008 at 5:35 am
I'm not sure this is what you're looking for, but maybe using the OUTPUT clause?:
INSERT INTO Person
OUTPUT PersonId INTO #Temp
.....
June 24, 2008 at 5:28 am
There's not really fine-grained control that will allow you to manipulate the cache in that manner. I have heard of a number cache problems with the release version and SP1....
June 24, 2008 at 5:23 am
Viewing 15 posts - 20,071 through 20,085 (of 22,212 total)