I ran your code against the Northwind database (assume that's where you were running it, as well)... Just to be sure, this is your code, isn't it (I added the...

City Index?  Neither the code you posted or my code would even come near a "city" index if the Primary Key was the CustomerID column.

The thing I'd like to add to Steve's good comments is that you should not use SELECT * It's, well... a bit lazy... and...

Actually, you can get ALL the column names at once with the commas at the end with the added benefit of carriage returns in just the right places... run this...

There's that "ISNUMERIC" thing again... see a couple of frames up for the warning

Alex,

Nice article especially for the proverbial "newbie".  I do agree that the examples were a bit overdone but how are ya going to learn if you don't try?

I've found that that is NOT true... not with INT ID's anyway... In my testing of the various solutions posted against this article, I get INDEX SCAN's, not table scans using WHERE (CustID...

Sorry... it's a "Moden-ism" pronounced "ree-bar" and stands for "Row By Agonizing Row"    Why "ree-bar"?  Because it's like the metal stakes stuck in...

Thanks for the feedback, Steve.

p.s. You would be amazed at just how useful that Tally table is gonna be...  and, a lot of the time, it will greatly enhance the performance of your code......

Aye... and thank you for the feedback, Perry.

p.s.  The above was from your original query... it does not include the change due to the "blond-attack"

Ugh!  Correlated Sub-Queries = Instant RBAR.  Not good... real performance killer.  Should be a derived table.  WHERE IN... not good... should be an equi-join (inner join).

Haven't tested it but I'm...

I don't use debuggers in SQL Server... just the ol' Mil Spec Mark I Mod I Eyeball.  Probably not what you wanted to hear, though...

What are you trying to debug...

I loved the examples... nice and simple.  Great job, DC.