Q: tabledefs in ADO and general ADO questions

[mdas]

Using Access 2000.

All,

I've been using DAO to do all my recordset and tabledef programming, but
have decided to do this new project using ADO, if possible. I need to get a
list of table names, then a list of fields in each table. I can do this with
DAO pretty easily, but have no clue how to do this in ADO. Any help?

Also, in general, can everything I do in DAO be also done in ADO? I'm tired
of always having to add the DAO reference.

Oh, and is there a good website that I can use as a tutorial?

Thanks,
-Mark

 

[Douglas J. Steele]

You can try using the ADO OpenSchema method (see
http://support.microsoft.com/?ID=186246 for details), or else read the ADOX
Catalog and its Tables and Fields collections (see
http://msdn.microsoft.com/library/en-us/ado270/htm/adoddlo1.asp for details)

No, there are things that you can do with DAO that you can't do with ADO.
For details, see what MichKa has to say at
http://www.trigeminal.com/usenet/usenet025.asp

Some good references are:
INFO: Issues Migrating from DAO/Jet to ADO/Jet
http://support.microsoft.com/?id=225048
Porting DAO Code to ADO with the Microsoft Jet Provider
http://msdn.microsoft.com/library/en-us/dndao/html/daotoado.asp
Migrating from DAO to ADO
http://msdn.microsoft.com/library/en-us/dndao/html/daotoadoupdate.asp
The ADO Rosetta Stone
http://msdn.microsoft.com/library/en-us/dnado/html/msdn_adorosest.asp

Having said all that, though, if you're strictly dealing with Jet databases
(i.e.: MDBs), DAO is still the way to go. DAO was designed specifically for
Jet databases. ADO is a generic approach, so it adds a couple of layers of
abstraction to the process. That means DAO will always perform as well as,
and usually better than, ADO.

 

[mdas]

Douglas,

Thanks so much!

-Mark

You can try using the ADO OpenSchema method (see
http://support.microsoft.com/?ID=186246 for details), or else read the ADOX
Catalog and its Tables and Fields collections (see
http://msdn.microsoft.com/library/en-us/ado270/htm/adoddlo1.asp for details)

No, there are things that you can do with DAO that you can't do with ADO.
For details, see what MichKa has to say at
http://www.trigeminal.com/usenet/usenet025.asp

Some good references are:
INFO: Issues Migrating from DAO/Jet to ADO/Jet
http://support.microsoft.com/?id=225048
Porting DAO Code to ADO with the Microsoft Jet Provider
http://msdn.microsoft.com/library/en-us/dndao/html/daotoado.asp
Migrating from DAO to ADO
http://msdn.microsoft.com/library/en-us/dndao/html/daotoadoupdate.asp
The ADO Rosetta Stone
http://msdn.microsoft.com/library/en-us/dnado/html/msdn_adorosest.asp

Having said all that, though, if you're strictly dealing with Jet databases
(i.e.: MDBs), DAO is still the way to go. DAO was designed specifically for
Jet databases. ADO is a generic approach, so it adds a couple of layers of
abstraction to the process. That means DAO will always perform as well as,
and usually better than, ADO.

--
Doug Steele, Microsoft Access MVP



get