Tables in one of my schemas are not listed in INFORMATION_SCHEMA.TABLES. What can be the reason? I have three schemas in my SQL Server database, but when I query over INFORMATION_SCHEMA.TABLES only tables that belong to two of the schemas are listed. Tables in the third schema are not listed. What can be the cause?

My query is:

USE MyDatabase
SELECT * FROM INFORMATION_SCHEMA.TABLES;


I think it is a permissions issue, but I can't find it. I have compared the schemas (and their owner roles) and their permissions look the same. I can't find any difference between them.

I want to list all the tables, not schemata. Even when I run SELECT * FROM INFORMATION_SCHEMA.SCHEMATA my third schema is not in the result.

When I run SELECT OBJECT_ID('Schema3.Table1') I receive NULL whereas the result for SELECT OBJECT_ID(Schema2.Table1)is the object_id.
Aaron Bertrand has an excellent post here about why you shouldn't trust the INFORMATION_SCHEMA views - unreliable information_schema schema information on SQL Server?

To summerize:


  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.