Prev: A Totals query problem
Next: Help with table design
From: The Frog on 16 Jul 2010 03:49
Hi David,

My use of ADO is actually mostly through Excel, not through Access,
and it talks to an Oracle backend. I find that the ease of maintenance
and the speed of operation in this context are extremely good.
Sometimes to save time I will take code from what has been developed
in Excel and re-use it in Access, hence the occasional ADO usage. It
doesnt happen very often, as I prefer to work with DAO in Access.

Someone mentioned above about ADO.Net. I find that this is a great
technology to work with and I really like the tool. I find it a shame
that AFAIK Access 2010 does not natively support .Net. You can do the
same things with code in Access as you can with ADO.Net, but I do like
the encapsulation that the .Net object(s) provide(s). The logic of its
operations make sense to me.

That being said, I seem to be spending more and more time writing
stuff in Java these days. I wish my office would upgrade to 2010, but
I dont think that is likely. I dont get to make the decisions!

Still, in answer to the OP's question, I would head with DAO, and
AFAIK it will be around for quite a while longer, so it is a skillset
well worth the mastering.

Cheers

The Frog
From: David W. Fenton on 16 Jul 2010 14:49
"Sven Pran" <no.direct(a)mail.please> wrote in
news:Os2dnfkLpah9B6LRnZ2dnUVZ876dnZ2d(a)telenor.com:

> "David W. Fenton" wrote
>> "Sven Pran" wrote>
>>> I am using ADO and didn't know about DAO at all, so I used
>>> Google to find some information. What I found on Wikipedia was
>>> among other things:
>>>
>>> "DAO 3.6 was the final version developed by Microsoft. Microsoft
>>> says that DAO will not be available in its future 64-bit
>>> operating systems."
>>>
>>> Worth some attention?
>>
>> Are falsehoods worth more attention than it takes to demonstrate
>> that they are false?
>>
>> It's patently untrue and was falsified by the release of Access
>> 2007 which implemented a new version of DAO (i.e., beyond 3.6).
>> The version and filenaming changed because it's part of the new
>> ACE rather than part of Jet (which is frozen at version 4 and
>> will not see further development).
>>
>> The 64-bit issue was falsified by the release of Access 2010 --
>> the 64-bit version of DAO is shipped with the 64-bit version of
>> the ACE that is included with the 64-bit version of Access.
>>
>> Don't believe what you read on Wikipedia. Don't believe what you
>> read on MS's own website, much of which has not been updated to
>> reflect the many zigs and zags of MS's development strategies.
>>
>> Please let us know what Wikipedia article that is, so it can be
>> corrected.
>
> http://en.wikipedia.org/wiki/Data_Access_Objects

I've added a comment in the discussion about the factual errors of
the article.

> I only referred what I found. To me DAO was of little interest as
> I use ADO for communicating with my Access databases and Excel
> workbooks from my applications developed in Delphi (at the time I
> use version 2007).

If you mentioned this somewhere upthread, I must have missed it.

> ADO seems to work fine for me and I hadn't even heard about DAO
> until I read about it here, so I just tried to find out what this
> is all about.
>
> I cannot say that I am much wiser..

It was not clear to me that you weren't developing in Access. I
believe that all the answers you received about DAO assumed you were
developing in Access, not in Delphi.

I don't know what's best in Delphi, because you're not using Access
then, only Jet/ACE, and that's not something most of who develop in
Access have to wrangle with on a regular basis. That is, the
interface with Jet/ACE is transparent and requires no code to
implement, so we generally only write code to do things the default
behaviors don't support.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 16 Jul 2010 14:50
Tony Toews <ttoews(a)telusplanet.net> wrote in
news:q0qv36tidmjtin0ir6e8k3kscf2skfi7lc(a)4ax.com:

> I think DAO typically takes one or two less lines of code because
> you don't have to create the new ADO object. Or something like
> that. I misremember the details now.

Hmm. If you used the default connection object, you wouldn't have to
recreate it, right? Or you could cache it just like you can with DAO
database variables.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: downwitch on 16 Jul 2010 17:08
My two cents: For the first 8 or so years of my dev work--up til
Access 2003 or so--I worked with DAO and Access back ends. Now, I work
with ADO whenever possible. I use Access tables only for local/temp
data, and primarily build client/server or OO apps, using Access only
because it's so quick for interface-building--it's just one interface
option in a growing world, and I expect being nimble in that regard is
more important than being dogmatic about one connection type or
another.

That said, DAO is being dragged along the upgrade cycle, but MSFT's
direction for future desktop dev just isn't clear enough, and I prefer
to think more .NET native than Office/VBA native, though I still
probably do 80% of my UI work in Office. ADODB and ADO.NET aren't
syntactically that different, and though I haven't re-benchmarked in a
while, I'm pretty confident OLEDB connections are faster than DAO
binding etc., so I'll keep resorting to DAO only when necessary (e.g.
to work with Access native objects like TableDefs and QueryDefs).

And yes, I reuse my own utility ADO connections and modules, so my
code is written quickly, concisely, and very readably. ;).
From: Access Developer on 16 Jul 2010 19:11
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" <XXXusenet(a)dfenton.com.invalid> wrote in message
news:Xns9DB5C55035211f99a49ed1d0c49c5bbb2(a)74.209.136.91...
> Banana <Banana(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/


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: A Totals query problem
Next: Help with table design