Everything the other guys said is 100% accurate, but one other note, you may want to take into account.... With really simple queries like the ones you showed, the optimizer...

I agree with GSquared. Both enabled, everywhere. Also a script that checks indexes and then does a rebuild or reindex based on fragmentation. Also, there is the occasional index or...

Or go up to the Search window just about here and type in TSQL and "SQL Server 2008" or "SQL Server 2005." You can filter by article then. There are...

Last I heard, they were still releasing in August. I haven't seen any definite release dates, but I haven't seen anything that said it was slipping.

Here's a post from...

Unwise, poorly worded, incomplete, untested, filled with mistakes, rebuttal!

Oooh, that's a lovely one Steve. There's a product to stay away from.

I'll bet these are the very same developers that are in full-throated howl against using stored procs...

That's a pretty standard approach. Not necessarily the most accurate since you're only capturing what's different, not specifically what needs to be moved. At some point, depending on your development...

Marios Philippopoulos (8/2/2008)

---

Grant Fritchey (8/2/2008)

---

And that's why we've only had to do the FULL SCAN in a few places and on a somewhat irregular basis. Most indexes, most of the...

It heppens to us all. That second set of eyes can work wonders sometimes.

The thing to remember is, to all intents and purposes, the clustered index, is the table.

You'll have to use dynamic SQL. Put everything into a string and concatenate the table name.

Here's an example (uncompiled, so test it):

DECLARE @mystring nvarchar(max)

SET @mystring = 'CREATE TABLE dbo.' +...

Why would you need a cursor? It sounds like a simple INSERT... SELECT DISTINCT... will do the job nicely in a single step. Avoid cursors any where and every where.

Well, not to give competition to Steve... OK, it won't, but there is

http://www.sqldumbass.com

And that's why we've only had to do the FULL SCAN in a few places and on a somewhat irregular basis. Most indexes, most of the time, if they were...

Sweet. Nice security. No one will ever know that we're running everything off an Access DB