Jim Dettman
jimdettman at verizon.net
Sat Jan 25 07:47:02 CST 2014
Yes, ADO does not run on top of DAO. They are two separate and distinct things. I think what John was thinking of is that ADO runs on top of OLEDB. ADO was developed as the object model for OLEDB technology. OLEDB was designed as the successor to ODBC, which focused on databases only as sources of data. OLEDB was designed to talk to just about anything; spreadsheets, text files, and databases as well. With that said, there are a couple of comments in regards to what Jim has said: 1. If your dealing with a JET DB, DAO is far faster then ADO. That's been proven time and time again. 2. If your dealing with a JET DB, with ADO you have to jump through some hoops to do what you can easily do in DAO. That's because DAO is more in-tune with Access and databases in general via ODBC. ADO is designed to work with everything, but nothing specifically. So when you get into the depths of a data source, using ADO/OLEDB takes extra work. That's not just with JET either. 3. ADO is a richer and more complex object model then DAO because it was designed to work with just about anything and it has to be in order to achieve that. 4. Even if you do use ADO, you may not get all the functionality it provides. It's the OLEDB provider of the data source that determines what you can do. As Jim pointed out, in ADO you have a multitude of different cursor types and ways to control it, but if your working with a JET DB, those are not available to you. In fact it can be down right confusing because you can ask for it, will get a recordset returned with no error, but you are given back a cursor type other then the one you requested (I actually consider this a fault of ADO). I think what I disagree with the most on Jim's comments is that implication that ADO "is the greatest". It's not. Like any other tool, it's has advantages in some situations and disadvantages in others. Also that DAO is some how only for power users and not a real developers object model. Just because it's simpler doesn't mean it's not. A smart developer is going to use the best possible tool for what their doing. If your working with a JET DB, then DAO is the best possible choice flat out. If your not doing using it and using ADO because it's "better", then I would say you're a poor developer. Tools and technologies are supposed to make your job as a developer easier, not harder. The other thing that is flat out wrong is that somehow DAO causes corruption in JET DB's. The corruptibility in JET DB's has nothing to do with the object model. If has to do with the fact that DB processing is done on each client and there is no server side process touching the DB, which can roll back things if an abnormal disconnect occurs. You can corrupt a JET DB just as easily with ADO as you can with DAO. Last thing I'd add, which many seem to be unaware of is that Microsoft has been slowing walking away from OLEDB (and hence ADO) back to ODBC. Basically they've admitted that it doesn't work as well as it should. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Benson Sent: Friday, January 24, 2014 03:12 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Problem of a listbox's response on network... Part 1 You are only correct if you consider access as an application running in its on thread. I am pretty sure that when I use Excel and ADOX, ADO, and JRO to build set relationships and control the contents and behavior of tables and other objects in Access that I am NOT using DAO at all. On Jan 24, 2014 10:17 AM, "John W Colby" <jwcolby at gmail.com> wrote: > >DAO is more for power users than for real developers. I am not sure I > would have got into ADO if there had been no other way. > > Excuse me? DAO is the database engine AND (more importantly) object model > for all of Access. DAO is for programmers who need to program to the metal > of forms, querydefs, controls and so forth. If you use ADO, it is all a > layer on top of DAO. > > I am not disagreeing that ADO has its place, but "for power users" is just > plain wrong. There is not an electron that flows through Access that DAO > does not steer. > > John W. Colby > > Reality is what refuses to go away > when you do not believe in it > > On 1/24/2014 1:32 AM, Jim Lawrence wrote: > >> Hi Charlotte: >> >> DAO is more for power users than for real developers. I am not sure I >> would have got into ADO if there had been no other way. >> >> But Access is one of the best ways to at least learn the basics of >> database design...it truly has (or is that had) one of the best data >> modelling capabilities. >> >> I hope you are enjoying your job of teaching relational database to >> uninitiated. Maybe you could, at some time in the future, be also giving >> advanced classes? >> >> Keep up the good work. >> >> Jim >> >> > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com