You know if you're getting different plans and different performance, you might have instances where one piece of data generates a plan that it can use and a seperate set...

I think I'm losing track of the thread. Where are you with this? Have you tried changing the indexes in any of the ways that have been proposed? Have any...

This is great! What a lot of fun, and really good information. I do like the DBA in traditional DBA garb doing the performance dance.

Agreed on using JOIN statements instead of IN statements.

Do you really need the DISTINCT? That's usually added when the data is bad, the structure is bad, or the where clauses...

Unless they're they're the only things in the field, then you could get away with:

SELECT...

FROM...

WHERE MyField = 'Project Managers Book'

OR MyField = 'The Project Book'

...

There was a time when I was recommending using this code to eliminate dynamic SQL and still have a multi-valued search query:

SELECT....

FROM....

WHERE...

AND CASE WHEN @LocationTypeId...

For literally the same index, COLA, COLB and COLA, COLB, no, I can't support that. I'd even say that's unsupportable if the first one was clustered and the second one...

Have you looked at the execution plans for the those specific queries? Scans, hash joins, cursors, anything like that in evidence?

We might just fit right in...

and

{click-whoosh}{click-whossh} I am the master now, Andy {click-whoosh}

Anyway, I finished running the simple tests. Here's a question given the following table & query, what might happen?

CREATE TABLE [dbo].[users](

[LogonID] [nvarchar](20) NOT...

Funny you should say that. I'm stepping through writing up samples in C# using nHibernate as I type this (well, right after I type this and right before). So far,...

Yep. You're in trouble now. I still haven't been able to get it fixed. A friend ripped out everything, including all references in the registry, and reinstalled 2005. He's running...

Oh, then it's not a covering index. Try adding the date column. It will be then.

I'm not sure if means anything in relation to LINQ and the other ORM products, but I've seen systems where the developers used ADO to automagically access the database. Small...

That's a pretty common PSS tactic. Until you're running the set of patches that they want to test against, they generally won't support you. Oh well, I've exhausted my feeble...