Something that I think is often overlooked in the .NET Framework is the cool stuff you can get at using OleDbSchemaGuid to retrieve database schema information. I just thought of this again earlier today when I was reviewing a C# database application where ADOX was used via interop to retrieve schema. Why use the extra overhead of interop to get to ADOX when you have something built into the framework that will accomplish most of what can be done via ADOX? However, you'll find that ADOX is used frequently for this kind of stuff in .NET and I think it is mainly because people do not know there is a managed alternative.

First of all, let me preface this all with saying that using OleDbSchemaGuid (or ADOX for that matter) is a great way for retrieving database independent schema information. For example, if your application will need to retrieve schema for an unknown OLE DB data source, could be SQL, Oracle, dBase, Access, Excel or even text. Using OleDbSchemaGuid will allow you to do so via OLE DB - completely independent of the underlying source. If you know that your application will always use a specific source, such as SQL Server, then there are always better platform specific ways to retrieve schema rowsets.

So moving on, since the fields in the OleDbSchemaGuid class maps to OLE DB schema rowsets, you won't be surprised that this class only exists in the System.Data.OleDb namespace, not in the SqlClient or other managed provider namespaces (if you need platform specific schema information then use the schema rowsets available in that platform). The syntax might seem a little confusing at first. Basically, you have to have a connected OleDbConnection object. You use the connection's GetOleDbSchemaTable method and pass to it the appropriate static member of the OleDbSchemaGuid class to indicate which type of schema rowset to return along with an object array to include any additional details (such as the table name to return columns for etc). A DataTable is returned that includes the schema rowset data. Take a look at some samples (we'll just bind the returned DataTables to some controls to keep things simple. Also note, in these examples, cn refers to an open OleDbConnection):

//Get the databases from connection & bind to combobox
DataTable t = cn.GetOleDbSchemaTable(OleDbSchemaGuid.Catalogs, new object[] {null});
cboCatalogs.DataSource = t;
cboCatalogs.DisplayMember = "CATALOG_NAME";

//Get tables for database (and assoc details) & bind to grid
DataTable t = cn.GetOleDbSchemaTable(OleDbSchemaGuid.Tables, new object[] {"myDatabase", null, null, null});
dataGrid1.DataSource = t;

//Get columns (and assoc details) for table & bind to grid
DataTable t = cn.GetOleDbSchemaTable(OleDbSchemaGuid.Columns, new object[] {"myDatabase", null, "myTable", null});
dataGrid2.DataSource = t;

Easy enough. It all goes way deeper than that, but that gets the point across. You can get to anything from catalogs/databases on a server, tables, columns, procedures, views, constraints, indexes, key information, character sets, object privileges, etc etc etc. The docs to cover what detail is passed in the object array for the various schema rowsets. The columns in the returned DataTable obviously differs from rowset to rowset. I don't believe those are in the docs so you'll need to play around and take a look. Take a look at each of the static fields in the OleDbSchemaGuid class for more details: OleDbSchemaGuid Members

With all that said, however, I do admit that there are some things that ADOX can do that you can't do with the OleDbSchemaGuid class. For example, you can actually create objects with ADOX, you can't do that here. But most of the times I see ADOX used in a .NET application that is not something being done anyway. If all you're doing is retrieving schema data, then this is the way to go. Easy to use, and in the framework.