>Thanks for the confirmation, Keith. Just wanted to be sure that this wasn't a(nother) case of me not being aware of some setting/property/config file somewhere, but this leads me to a question about your P.S. statement...
>
>In the beforetime, when I was relatively server agnostic, "a friend" was under the impression that all PKs should be clustered. Then, I filled my head with book knowledge...

Jason,

The books you read were correct about indexing for speed. My flippancy was more along the lines of a unique clustered composite index - which is usually an indicator that the columns in the key should actually be foreign keys. I.e. because those columns are (i'm assuming) readable text, and because combined they uniquely identify the row, they should be in one or more separate tables. Bleh, it's not easy to put into words.

>..., reading that clustered indexes should "always" be set up relative to either the most used sort order or the most likely insert order for "high volume" tables, which is not always by our PKs (sp-generated surrogate keys). So, it seemed that in some cases our PK indexes should not always be clustered if we wanted peak-ish performance.

This is really dependant on whether your system is closer to OLTP or OLAP. OLTP is all about da' inserts, OLAP is all about da' sorts. If all of your joins are on PKs and FKs (I hope they are), then clustered PKs can speed up queries greatly. If most of your queries are flat, then sort order becomes the primary concern.

>
>Now, having typed that mouthful, I'm not sure it applies to this particular table (a hired gun "guru" implemented it in our test system as part of index tuning and I'm going to take it up with him, as I think the column he added to make the composite key is superfluous for our business rules) but I'm just curious as to where I should find some guidelines for this sort of index setup.
> In reality, away from the gentle confines of academia, is it considered a particularly poor idea to have PKs unclustered? And if so, why?
>

Not at all. It depends on what you want to do with the data - queries or insert/update/delete.

>I thank you in advance for your infinite patience and wisdom in regards to this matter.
>---J
>
>>Jason,
>>
>>This is actually a bug in the SQL ADO.NET provider. ADO.NET relies on the GetSchemaTable method to discover keys and constraints. If you want to see where the confusion comes from, just look at the help for this method :)
>>
>>P.S. Shame on you for clustering something other than your PK! Time to move those clustered keys to their own tables. Remember rule #3 - Eliminate columns not dependent on the key (and move them to a separate table).
>>
>>Either that or shoot the DBA.
>>
>>JUST JOKING!
>>
>>- Keith