Prev: A Totals query problem
Next: Help with table design
From: klar on 19 Jul 2010 21:06
On Jul 17, 7:11 am, "Access Developer" <accde...(a)gmail.com> wrote:
> I've done work on only one ADP (which, of course, required ADO), did not
> find the much-touted "simpler object model" to be helpful, because <in Gomer
> Pyle accent, "Sur-prize, sur-prize, sur-prize!> you have to provide all the
> same information, only in slightly different form.  I've done apps ranging
> from individual apps to LAN/WAN apps for a Fortune 100 company, and never
> had a _need_ that DAO and ODBC did not answer, from 1993 until now.
>
> I don't doubt that if I'd wasted (and I use the word advisedly) my time
> delving deep into ADO, I might have found a few (from my observations, very
> few) things that would be either simpler or possible in ADO as opposed to
> DAO. I do very strongly doubt that the ROI on the time I spent delving deep
> into ADO would have been positive.
>
> --
> Larry Linson, Microsoft Office Access MVP
> Co-author: "Microsoft Access Small Business Solutions", published by Wiley
> Access newsgroup support is alive and well in USENET
> comp.databases.ms-access
>
> "David W. Fenton" <XXXuse...(a)dfenton.com.invalid> wrote in messagenews:Xns9DB5C55035211f99a49ed1d0c49c5bbb2(a)74.209.136.91...
>
> > Banana <Ban...(a)Republic.com> wrote in
> >news:4C3E35C1.3010809(a)Republic.com:
>
> >> 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?
>
> > I did not say that. I said "never use anything but DAO as your
> > DEFAULT DATABASE INTERFACE." That doesn't say "never use anything
> > else" -- it only says use DAO as the default until you need
> > something DAO can't do or doesn't do well, and then use the
> > non-default interface.
>
> >> 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.
>
> > This is 100% consistent with what I wrote.
>
> >> 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).
>
> > There is no contradiction between your practice and my principle as
> > I very carefully worded it. You read something different than the
> > plain sense of what I wrote, however.
>
> > --
> > David W. Fenton                  http://www.dfenton.com/
> > usenet at dfenton dot com    http://www.dfenton.com/DFA/

Thank you to all the experts who answered. The choice is clear. Based
on the number of supporters among the experts for DAO, DAO is the way
to go
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: A Totals query problem
Next: Help with table design