Prev: A Totals query problem
Next: Help with table design
From: klar on 14 Jul 2010 04:14 Dear Access experts, I have no experience writing ADO or DAO code but I am going to start soon. After reading up on ADO and DAO, it seems both can do the job for me. However, I do not know enough to know which one to choose. I am using Access2003 and the database will be used locally, not on a client-server environment. I will be mainly using ADO/DAO for queries. My preferred choice is the one with more readable code. Can the experts here advise me ADO or DAO? Thank you very much.
From: Bob Barrows on 14 Jul 2010 07:36 klar wrote: > Dear Access experts, > > I have no experience writing ADO or DAO code but I am going to start > soon. After reading up on ADO and DAO, it seems both can do the job > for me. However, I do not know enough to know which one to choose. > > I am using Access2003 and the database will be used locally, not on a > client-server environment. I will be mainly using ADO/DAO for queries. > My preferred choice is the one with more readable code. Can the > experts here advise me ADO or DAO? > They are both equally "readable". DAO can do a few more things with a Jet backend (.mdb) than can be done with ADO, so my preference would be DAO.
From: Douglas J. Steele on 14 Jul 2010 07:37 The issue shouldn't be which is more readable (they're pretty much the same), but which is better. From the sounds of it, you're talking about using strictly Jet databases (i.e.: MDBs). That means you should use DAO. -- Doug Steele, Microsoft Access MVP http://www.AccessMVP.com/DJSteele Co-author: Access 2010 Solutions, published by Wiley (no e-mails, please!) "klar" <klarbuf(a)gmail.com> wrote in message news:983515f6-2bdd-40a1-9141-9ca1cf410945(a)h8g2000prn.googlegroups.com... > Dear Access experts, > > I have no experience writing ADO or DAO code but I am going to start > soon. After reading up on ADO and DAO, it seems both can do the job > for me. However, I do not know enough to know which one to choose. > > I am using Access2003 and the database will be used locally, not on a > client-server environment. I will be mainly using ADO/DAO for queries. > My preferred choice is the one with more readable code. Can the > experts here advise me ADO or DAO? > > Thank you very much.
From: David W. Fenton on 14 Jul 2010 14:23 "Douglas J. Steele" <NOSPAM_djsteele(a)NOSPAM_gmail.com> wrote in news:i1k7h9$dbo$1(a)news.eternal-september.org: > From the sounds of it, you're talking about using strictly Jet > databases (i.e.: MDBs). That means you should use DAO. It's not a matter of whether you're using an MDB or ACCDB to store your data, but whether or not you're using Jet/ACE to access your data. With MDB/ACCDB, its axiomatic that you're doing so. But it's also the case that if you're accessing a different database engine via ODBC, you're also using Jet/ACE, and in that case DAO is the best choice. So, use DAO for any MDB/ACCDB back end, or any back end accessed through ODBC. From where I sit, this basically means that you never use anything but DAO as your default database interface, since there's no reason why you'd be using anything other than MDB/ACCDB/ODBC. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Banana on 14 Jul 2010 18:10
On 7/14/10 11:23 AM, David W. Fenton wrote: > So, use DAO for any MDB/ACCDB back end, or any back end accessed > through ODBC. > > From where I sit, this basically means that you never use anything > but DAO as your default database interface, since there's no reason > why you'd be using anything other than MDB/ACCDB/ODBC. I'm reminded of the adage, "When the only tool you have in hand is a hammer, everything looks like nails." ;) With a Jet backend, I very much agree that DAO is really the only tool we need. With ODBC backend, there are already a lot of things we can do even going through Jet that it's conceivable that we can build a good front-end client using nothing but DAO. But would I go as far to say it should be the *only* tool? No, not really. I do reach for ADO when there is a specific need for it, and it has served me well in few cases where DAO came up short. The cases are quite rare but when it does happen, I'm glad to have the luxury of choosing a different data access technology, even if ADO is dormant and superseded by newer technologies (in which I also hope the Access team will remedy somehow). |