Jim Lawrence
accessd at shaw.ca
Sat Jan 25 13:58:43 CST 2014
Hi Jim: A lot of what you say is correct but: 1. OLE is traditional faster than ODBC. I was actually surprised that ADO is still supported even on Windows 8x. Note: One of the main reasons that ADO was chosen because it would basically require a tech to either remote in or go on site to accommodate/install an ODBC connection. ADO just worked. 2. If you are just working in a tight network world DAO is the best performer but when there is external data sources or the client does not necessarily have a complete unique set of Microsoft products, on purpose or accidentally, there can be any number of issues caused. Even the governments, with complete legal site licences was not immune to this situation....deployment can get very complex. I used to make a big fuss about this but now I don't care. straight 3. Over the years I have had many cases where an MDB has corrupted. I just wish there was a feature where a DAO connection could be disconnected automatically. Within the government there were many such situations as the main MDB was situated on a server and some clients did not log-off, from an application, at night. The servers would be rebooted regularly as updates came through. The results were predictable. 4. It all depends on what type of environment you find yourself in. That is why there was a rather lengthy preamble to the whole ADO-DAO topic. The major issues were, a far flung, huge network, many users and limited database resources. If an attempt to roll out a DAO type network, in this environment, it would have failed and the project would have never happened. It was not that ADO is greatest; it is that it was the MS Access only option...so for that case it was the greatest. In summary, it all goes to prove, that if done right there is really no limits to how big a MS Access network could be. Aside: As for the future of ADO or even the latest buggy version of desktop Access (...interesting enough I spent two hours on the phone, yesterday helping a fellow developer (another 35 year computer veteran), get the latest version of Access to behave...he was hoping to have a demo ready for today...I will call him later and report back his success or otherwise), I care little, as times have moved on. The web (internet or intranet) is where new developers are spending their time, along with the appropriate database and even MS Access, or what is left of it, is migrating that way as well. Jim ----- Original Message ----- From: "Jim Dettman" <jimdettman at verizon.net> To: "Access Developers discussion and problem solving" <accessd at databaseadvisors.com> Sent: Saturday, January 25, 2014 5:47:02 AM Subject: Re: [AccessD] Problem of a listbox's response on network... Part 1 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 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com