[AccessD] Problem of a listbox's response on network... Part 1

William Benson vbacreations at gmail.com
Sun Jan 26 00:27:28 CST 2014


Good points.

I weite code I can use in as many circumstances as possible unless my
client is specific in terms of performance and I cannot meet their needs
with ADO, I am going with that. Because it comes with Windows. I just have
to make sure references are present and if not, add them, knowing they will
exits. Usually by GUID. And I can promise solitions with jet backends that
neither require Access licenses nor violate IT policies prohibiting Access.

I just play with the hand I am dealt. If they give me Access to work with
and I can create a reference to DAO on everyone's machine then fine, but I
have often found that to not be real... and like I (may not have) said my
ability to deliver a timely solution has proven more important than
building the world's best.  ADO lets me do that, hands and I can be done
before I hear "Pencils down!" And no one writes me telling me that they
cannot eun my app because they don't have access or the latest version (s).

That is about all I have to say, I don't have a sog in the fight of which
is "best" and am not paid to do anything other than make something work.
Making it work fast was not as important asaking it work, FAST!
On Jan 25, 2014 8:47 AM, "Jim Dettman" <jimdettman at verizon.net> wrote:

>
>   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
>


More information about the AccessD mailing list