unreliable information_schema schema information on SQL Server?

It's a shame this went unanswered and just commented so partially out of rep greed and more importantly to get it out of the unanswered queue, I'll throw a few points into an answer.

1. The wording in the documentation is not accurate, and it is in the process of being corrected (see Connect #686118). I'm not sure if they will correct the 2005, 2008 and 2008 R2 docs all at once, or whether the older versions will even get updated. The point is that I can not envision a case where the schema in either view is incorrect, but even more so, that info_schema is incorrect while sys.objects is correct. The latter is impossible - the info_schema view is based entirely on the sys.objects view (just look at SELECT OBJECT_DEFINITION (OBJECT_ID ('INFORMATION_SCHEMA.TABLES'));), so if one is incorrect, they're both incorrect. There are probably obscure cases where they can both be incorrect, but not in current versions (for example, in SQL Server 2000, with the config option allow updates enabled, delete from sysusers a user who owns an object - not really relevant or possible today, and not something I'm willing to try, but it's the only one I can imagine would have motivated the current wording at any point in time).

2. In general, INFORMATION_SCHEMA views should be avoided in favor of the catalog views introduced in SQL Server 2005 (and augmented since then). Why? Because the catalog views continue being developed as new features are added to SQL Server, while the info_schema views have not. As I mentioned in my comment, try to find information about filtered indexes in info_schema. Same goes for included columns, XML indexes, identity/computed columns, foreign keys against unique indexes - these are all either missing entirely or represented differently in the info_schema views. In Denali they added an info_schema view for Sequences but again this meets the bare minimum of the standard and doesn't include any information about SQL Server-specific implementation details (for example, whether it's exhausted, and if they add any new features in the future you can be sure the info_schema view will not be kept in the loop). The only case where you would stick to info_schema views is if (a) you are writing metadata routines that need to work across info_schema-compliant platforms AND (b) you aren't using any platform-specific features that will be missed. Aside from multi-platform vendor tools this is probably a pretty rare scenario (and even in that case may lead to displeased customers who are using those features and the tool didn't pick them up).

3. I filed a separate Connect suggestion (Connect #686121) that they plaster a warning about this incompleteness on all INFORMATION_SCHEMA view topics in Books Online. I don't think it's very well known that they are not the preferred way to get metadata out of SQL Server, and who could blame folks for not seeing this - after all, we're always told that using standards-compliant methods is a "best practice" and using proprietary methods are the opposite. As with a lot of database things, "it depends" - but I suspect, more often than not, you're better off using the sys catalog views unless you're in that rare scenario where you're using only the features in SQL Server that are common to the standard. I don't think I've come across a single instance in any capacity where this was the case, but I'm more than happy to learn of them if they do exist.

I've also blogged about the unreliability of INFORMATION_SCHEMA here:

• The case against INFORMATION_SCHEMA views