And the execution plan?

Plus, how often does the index get rebuilt or the statistics get updated?

Further, since as you say this isn't your database, if the owner has set up security appropriately, you probably won't have DDL permissions.

Everything everyone else said is 100% true. Just understand that if you don't need case sensitivity, using it just to be cool can add an incredible amount of overhead to...

Designing web pages & managing databases are two different beasties. But since you ask, I have all of the Inside SQL Server 2005 series sitting on my desk, well thumbed...

We've actually got a method that does this pretty well. We try to use it sparingly, but some of our reports from some of our systems have legitimate requirements to...

And be sure to check the execution plan to be sure that indexes are being used at all.

Even if you don't explicitly state a return value, all stored procedures have one. I prefer to do something along these lines in 2005 (similar, but different error handling, in...

As the size of the database increases, sp_updatestats can degrade pretty seriously. You may need to identify those particular tables or indexes that need more frequent updates and use UPDATE...

Strings are supposed to be surrounded with single quote marks. Quoted Identifiers allows you to put double quote marks around reserved and key words to use them as objects within...

fn_listextendedproperty, as you've found, only returns values where those values exist. What you'd need to do is combine the output of that query through a left join with a valid...

Theres a catalog view sys.extended_properties. You should be able to pull it right out of there.

You could output as XML and then pass it on to the presentation layer, but it'd probably be a lot easier overall to format the output on the app.

Cool, 128 character three place numbers. I use those all the time.

I like Mark's because it will only return those customers who have orders in all the included years. Much more precise.

It's hardly optimal, but you could:

SELECT...

FROM...

WHERE YEAR(OrderDate) IN (2001,2002,2003,2007)

You could add those values to a temp table & join on it. That would probably be better than than in IN...