Prev: A Totals query problem
Next: Help with table design
From: David W. Fenton on 14 Jul 2010 19:23
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/
From: rkc on 14 Jul 2010 20:56
How readable your code is depends entirely on your skills.

Both ADODB and DAO are made up of a conglomeration of objects
and collections of objects that you have to wade through in order
to do much of anything.

It's real easy to write ugly repetitive code using either.
From: The Frog on 15 Jul 2010 03:57
Like David said, if the BE is MDB or an ODBC then I use DAO. If on the
other hand I want to be able to talk directly to a server at some
point in the future (scaling up) and really want performance then I
tend to dodge ODBC connections and instead use ADO to talk to the
database server directly. It really depends on the app that is being
built and the expected implementation - you can swap out an ADO
connection to a different DB type quite easily if you need to.

That being said, most of the stuff I write is DAO based as the
requirement for ADO really doesnt exist for most cases. Jet with DAO
works really well, its well tested and well understood. Keeping your
code clean is another matter entirely. If you compare the code
required to run a select query via DAO and ADO they are actually
pretty similar in both form and logic. Its not hard to translate
between them with a little practice.

For most things, in Access, I would suggest DAO if you need to do
code. You might also consider using queries and linked tables (for
external data like a Back End (BE) MDB file). Depends on your use
case, but I typically find they are fast, friendly, and reliable.

Cheers

The Frog
From: Sven Pran on 15 Jul 2010 05:47

"The Frog" <mr.frog.to.you(a)googlemail.com> wrote in message
news:fb0c705e-e29c-4590-88a2-36e678fd7e70(a)j4g2000yqh.googlegroups.com...
> Like David said, if the BE is MDB or an ODBC then I use DAO. If on the
> other hand I want to be able to talk directly to a server at some
> point in the future (scaling up) and really want performance then I
> tend to dodge ODBC connections and instead use ADO to talk to the
> database server directly. It really depends on the app that is being
> built and the expected implementation - you can swap out an ADO
> connection to a different DB type quite easily if you need to.
>
> That being said, most of the stuff I write is DAO based as the
> requirement for ADO really doesnt exist for most cases. Jet with DAO
> works really well, its well tested and well understood. Keeping your
> code clean is another matter entirely. If you compare the code
> required to run a select query via DAO and ADO they are actually
> pretty similar in both form and logic. Its not hard to translate
> between them with a little practice.
>
> For most things, in Access, I would suggest DAO if you need to do
> code. You might also consider using queries and linked tables (for
> external data like a Back End (BE) MDB file). Depends on your use
> case, but I typically find they are fast, friendly, and reliable.

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?

Sven

From: Banana on 15 Jul 2010 08:14
On 7/15/10 2:47 AM, Sven Pran wrote:
> "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?
>
> Sven

I expect that if you follow the source back to the MSDN, you would find
that the declaration of deprecation would be for a completely different
context. It used to be that DAO and Jet was considered to be a part of
Windows and Access was basically the GUI layer to those technology. So
in a sense, you could basically run any Access .mdb on any Windows
computer even without Access installed as long your custom program used
DAO/Jet which is rare nowadays as programmers are more likely to use ADO
or OLEDB if the Jet is used as a data source nowadays. Note that they
may not even always choose Jet now that they also could use SQL Server
Compact Edition or SQL Server Express Edition (both are free) or even a
different embedded database program. I understand SSEE is the preferred
engine when wanting to do small scale web development for example.

But the above doesn't really apply in the context of Access development,
and more especially so that Access team also has privatized the
underlying technology since post-2003. When Access team took control of
those technology, - which I suspect is a part of reason why it was
named ACEDAO and ACE for DAO and Jet, respectively - they have been
actively developing those technology.

ADO, OTOH, is in maintenance mode since ADO.NET is designated successor
and has not had any active development though it continues to be
included in MDAC. I would actually expect ADO to diminish in
significance as time go by both in context of general programming and in
Access development.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: A Totals query problem
Next: Help with table design