Beginner Question: DAO vs. ADODB

[Susan Bricker]

Hi. I am a relative "newbie" who has been asked to create a database
for a Dog Competition Organization. I have created databases (for my
use) just for fun to organize a practice Dog Obedience Competition
another to organize those fun projects, I felt comfortable enough to
tack a database for work to manage software releases (I'm a programmer
for a major US Bank) for my department. I did this on my own time and
"sold" it to my manager after it was up and running. What a coup!!!
Each database project that I've worked on has been better that the
previous one, as I have improved my VBA and MS/ACCESS skills. For work,
I work in a Mainframe environment coding in Assembler, PL/TPF, and C
(plus some REXX EXEC on the side).

I hate to admit it, though, that I have exclusively used DAO in the VBA
behind forms and reports. Mostly just because I picked up the concepts
and commands and definitions and simply stuck with them.

Now, I have this "paying" project (that Dog Competition Organization
Database) to create and I thought I should truly understand DAO vs.
ADODB so that I could intelligently choose before I begin my new
project.

So ...

Is there a source for me to read that will clearly explain when to use
DAO vs. ADODB? I will be developing my new "project" in Access 2003
(Windows XP).

Or

If there is anyone who can give a brief explanation and suggestions in a
reply post ... that would be GREAT.

Thanks, in advance, for all your help.

Regards,
SueB
sl*****@verizon.net

*** Sent via Developersdex http://www.developersdex.com ***

[Steve Jorgensen]

Here's my rule:

When in MS Access (any version), use DAO except and until you have a specific
case where ADO would be useful. It's OK to mix/match both libraries in one
application, but Access will force you to use some DAO anyway (unless you're
using ADPs which I don't recommend), so it's more consistent to make DAO your
default.

In any VB/VBA outside of MS Access, use ADO except/until you have a specific
case where DAO would be useful. There are some MDB database maintenance
operations that are still not possible in ADO.
On Mon, 11 Apr 2005 14:20:14 GMT, Susan Bricker <sl*****@verizon.net> wrote:

Hi. I am a relative "newbie" who has been asked to create a database
for a Dog Competition Organization. I have created databases (for my
use) just for fun to organize a practice Dog Obedience Competition
another to organize those fun projects, I felt comfortable enough to
tack a database for work to manage software releases (I'm a programmer
for a major US Bank) for my department. I did this on my own time and
"sold" it to my manager after it was up and running. What a coup!!!
Each database project that I've worked on has been better that the
previous one, as I have improved my VBA and MS/ACCESS skills. For work,
I work in a Mainframe environment coding in Assembler, PL/TPF, and C
(plus some REXX EXEC on the side).

I hate to admit it, though, that I have exclusively used DAO in the VBA
behind forms and reports. Mostly just because I picked up the concepts
and commands and definitions and simply stuck with them.

Now, I have this "paying" project (that Dog Competition Organization
Database) to create and I thought I should truly understand DAO vs.
ADODB so that I could intelligently choose before I begin my new
project.

So ...

Is there a source for me to read that will clearly explain when to use
DAO vs. ADODB? I will be developing my new "project" in Access 2003
(Windows XP).

Or

If there is anyone who can give a brief explanation and suggestions in a
reply post ... that would be GREAT.

Thanks, in advance, for all your help.

Regards,
SueB
sl*****@verizon.net

*** Sent via Developersdex http://www.developersdex.com ***

[Susan Bricker]

Steve,
Thank you for your input. By the way, I don't know what happened to my
original post. It looks like when I was editting it I deleted some
words here and there. I really don't write (or speak) like that!!! : )

Thanks again.
SueB
*** Sent via Developersdex http://www.developersdex.com ***

[ng]

That's interesting Steve. At first I thought those ADP's were the cats
meow, until I realized how completely different they are. Microsoft would
like you to beliveve that if you're a seasoned access person, that you'll
get these ADPs right away and the whole world will be a panacia. BS. Like
DAO, ADO, ADOX, ADOXDB or WHATEVER ELSE they have coming down the pipeline.
I don't get the feeling that microsoft really has their heart in this ADP
thing, that's why *I* decided not to go ahead with any further development
using ADPs. I'm not afraid to learn a new language/process/whatever, I just
don't want to waste my time learning some microsoft proprietary product,
when it looks to me like they'll drop it, or not put their full steam into
it.

I love DAO. It does what I need, I see nothing in in ADO...ADoxDDBOBO that
is worth switching for.

-dp

"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:um********************************@4ax.com...

Here's my rule:

When in MS Access (any version), use DAO except and until you have a
specific
case where ADO would be useful. It's OK to mix/match both libraries in
one
application, but Access will force you to use some DAO anyway (unless
you're
using ADPs which I don't recommend), so it's more consistent to make DAO
your
default.

In any VB/VBA outside of MS Access, use ADO except/until you have a
specific
case where DAO would be useful. There are some MDB database maintenance
operations that are still not possible in ADO.
On Mon, 11 Apr 2005 14:20:14 GMT, Susan Bricker <sl*****@verizon.net>
wrote:

Hi. I am a relative "newbie" who has been asked to create a database
for a Dog Competition Organization. I have created databases (for my
use) just for fun to organize a practice Dog Obedience Competition
another to organize those fun projects, I felt comfortable enough to
tack a database for work to manage software releases (I'm a programmer
for a major US Bank) for my department. I did this on my own time and
"sold" it to my manager after it was up and running. What a coup!!!
Each database project that I've worked on has been better that the
previous one, as I have improved my VBA and MS/ACCESS skills. For work,
I work in a Mainframe environment coding in Assembler, PL/TPF, and C
(plus some REXX EXEC on the side).

I hate to admit it, though, that I have exclusively used DAO in the VBA
behind forms and reports. Mostly just because I picked up the concepts
and commands and definitions and simply stuck with them.

Now, I have this "paying" project (that Dog Competition Organization
Database) to create and I thought I should truly understand DAO vs.
ADODB so that I could intelligently choose before I begin my new
project.

So ...

Is there a source for me to read that will clearly explain when to use
DAO vs. ADODB? I will be developing my new "project" in Access 2003
(Windows XP).

Or

If there is anyone who can give a brief explanation and suggestions in a
reply post ... that would be GREAT.

Thanks, in advance, for all your help.

Regards,
SueB
sl*****@verizon.net

*** Sent via Developersdex http://www.developersdex.com ***

[Susan Bricker]

Greetings. Thank you for your input. Sorry if this is really a basic
question, but what is ADP (as referred to in one of the replies here?
Also, I still would like to have an understanding of DAO and ADODB. Is
there a good book, article, or website that I can go to for information?

Thanks.
SueB

*** Sent via Developersdex http://www.developersdex.com ***

[David W. Fenton]

Susan Bricker <sl*****@verizon.net> wrote in
news:yI*************@news.uswest.net:

I hate to admit it, though, that I have exclusively used DAO in
the VBA behind forms and reports.

There's nothing to admit.

ADO is of virtually no use in an Access application manipulating
data stored in Jet databases (i.e., MDB files).

It is quite useful if you're back end is SQL Server.

Other than that, the ADO thing was a massive hoax perpetrated by
Microsoft's marketing department, i.e., people who didn't have any
comprehension whatsoever of the technical issues involved.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Susan Bricker <sl*****@verizon.net> wrote in
news:8u***************@news.uswest.net:

Greetings. Thank you for your input. Sorry if this is really a
basic question, but what is ADP (as referred to in one of the
replies here? . . .
An Access Data Project. It is a misguided attempt to create an
Access front end that doesn't involve Jet (which is impossible as
long as you're using the Access executable itself). It's for people
who are allergic to Jet because they never learned how to manage it
in a client/server environment. ADPs are of use only for creating
applications that run against MS SQL Server back ends, and each
version of Access has serious bugs in the implementation, bugs that
are sometimes fixed in one version and then re-appear in the next.
And some things that worked fine in early versions are broken in
later versions.

If you're thinking that ADPs are something you can completely
ignore, you're absolutely right.
. . . Also, I still would like to have an understanding of
DAO and ADODB. Is there a good book, article, or website that I
can go to for information?

The ADO that you have available to you in Access has already been
abandoned by Microsoft in favor of ADO.NET, which is not yet
supported in Access.

My advice is to ignore ADO until you have a need for it. If you're
not building applications to run against SQL Server, then you have
no need for ADO at all.

In other words: don't waste your time.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

On Mon, 11 Apr 2005 20:21:28 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Susan Bricker <sl*****@verizon.net> wrote in
news:yI*************@news.uswest.net:

I hate to admit it, though, that I have exclusively used DAO in
the VBA behind forms and reports.

There's nothing to admit.

ADO is of virtually no use in an Access application manipulating
data stored in Jet databases (i.e., MDB files).

It is quite useful if you're back end is SQL Server.

Other than that, the ADO thing was a massive hoax perpetrated by
Microsoft's marketing department, i.e., people who didn't have any
comprehension whatsoever of the technical issues involved.

Oh, I give them a bit more credit than that. ADO was a reasonable-seeming
effort to unify the common aspects of how persistent data is read/written to
databases, file systems, etc. It also included some genuine fixes to object
model strangeness, and some big improvements in handling stateless
connections.

Unfortunately, it's also an overengineered, top-heavy, fragile,
freature-creeped beheamoth. Oh well - nothing's perfect <g>.

[Tom van Stiphout]

On Mon, 11 Apr 2005 19:46:12 GMT, Susan Bricker <sl*****@verizon.net>
wrote:

David's opinion is not universally shared, although he certainly is
not alone.
At my company we have written several extensive ADP applications. Of
course we're hitting SQL Server and everyone is pleased with speed of
development and performance of the app. Yes we have run into some eh,
ideosyncracies of ADP, but we haven't had nearly as many problems as
some have reported. I wouldn't recommend it to a beginner, though.

If you have no need for a SQL Server back-end database, you might as
well stay with DAO. Going with ADO against an Access backend doesn't
make much sense.

-Tom.

Greetings. Thank you for your input. Sorry if this is really a basic
question, but what is ADP (as referred to in one of the replies here?
Also, I still would like to have an understanding of DAO and ADODB. Is
there a good book, article, or website that I can go to for information?

Thanks.
SueB

*** Sent via Developersdex http://www.developersdex.com ***

[Susan Bricker]

Thank you ALL for your input. I love this News Group. I learn
something EVERY time I get on and check the list.

SueB
*** Sent via Developersdex http://www.developersdex.com ***

[ng]

Wow. That is pretty scathing. I wrote one application that queries a HUGE
SQL database in an ADP. The application runs quicker than a race horse -
and SIGNIFICANTLY faster than the regular MDB version of the same report.
Great. But the extra work involved in trying to get that ADP to work, and
now you get basically NONE of the access tools to help you, I thinking just
as you are David, "This is too much trouble, and my users don't always need
this kind of speed." For this one particular app, that queried a tables
with over a million records, it was good, but that's the end of my ADP
experience.

-B

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.90...

Susan Bricker <sl*****@verizon.net> wrote in
news:8u***************@news.uswest.net:

Greetings. Thank you for your input. Sorry if this is really a
basic question, but what is ADP (as referred to in one of the
replies here? . . .

An Access Data Project. It is a misguided attempt to create an
Access front end that doesn't involve Jet (which is impossible as
long as you're using the Access executable itself). It's for people
who are allergic to Jet because they never learned how to manage it
in a client/server environment. ADPs are of use only for creating
applications that run against MS SQL Server back ends, and each
version of Access has serious bugs in the implementation, bugs that
are sometimes fixed in one version and then re-appear in the next.
And some things that worked fine in early versions are broken in
later versions.

If you're thinking that ADPs are something you can completely
ignore, you're absolutely right.

. . . Also, I still would like to have an understanding of
DAO and ADODB. Is there a good book, article, or website that I
can go to for information?

The ADO that you have available to you in Access has already been
abandoned by Microsoft in favor of ADO.NET, which is not yet
supported in Access.

My advice is to ignore ADO until you have a need for it. If you're
not building applications to run against SQL Server, then you have
no need for ADO at all.

In other words: don't waste your time.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:6s********************************@4ax.com:

On Mon, 11 Apr 2005 20:21:28 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Susan Bricker <sl*****@verizon.net> wrote in
news:yI*************@news.uswest.net:

I hate to admit it, though, that I have exclusively used DAO in
the VBA behind forms and reports.
There's nothing to admit.

ADO is of virtually no use in an Access application manipulating
data stored in Jet databases (i.e., MDB files).

It is quite useful if you're back end is SQL Server.

Other than that, the ADO thing was a massive hoax perpetrated by
Microsoft's marketing department, i.e., people who didn't have any
comprehension whatsoever of the technical issues involved.

Oh, I give them a bit more credit than that. ADO was a
reasonable-seeming effort to unify the common aspects of how
persistent data is read/written to databases, file systems, etc.
It also included some genuine fixes to object model strangeness,
and some big improvements in handling stateless connections.

I only meant the way ADO was marketed in Access was a hoax.
Unfortunately, it's also an overengineered, top-heavy, fragile,
freature-creeped beheamoth. Oh well - nothing's perfect <g>.

Well, ODBC did need to be updated to reflect modern server DBs.
Microsoft just went too far, in my opinion, putting too much smarts
into ADO.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[(Pete Cresswell)]

Per ng:

and my users don't always need
this kind of speed."

What speed does an ADP give that can't be gotten by writing stored procedures or
views on the server?
--
PeteCresswell

[Larry Linson]

"David W. Fenton" wrote

Microsoft just went too far, in my
opinion, putting too much smarts
into ADO.

And, in not following through to make it work correctly, nor as well as DAO.
Did you realize that a Find can only have one Field as a Condition in ADO?

When I saw that Lyle had abandoned ADPs, I was convinced that those of us
who had not invested time, energy, and emotion in ADO / ADP had done the
right thing. I said I would use ADP/ADO only when I had a client who
demanded it; I did have such a client; I did work with it for several
months; I did make everything work that I needed to do (most of which was
rather simple), but I was, at best, UNDERwhelmed.

Larry Linson
Microsoft Access MVP

[David W. Fenton]

"Larry Linson" <bo*****@localhost.not> wrote in
news:OKX6e.14467$ox3.6761@trnddc03:

"David W. Fenton" wrote

Microsoft just went too far, in my
opinion, putting too much smarts
into ADO.

And, in not following through to make it work correctly, nor as
well as DAO. Did you realize that a Find can only have one Field
as a Condition in ADO?

When I saw that Lyle had abandoned ADPs, I was convinced that
those of us who had not invested time, energy, and emotion in ADO
/ ADP had done the right thing. I said I would use ADP/ADO only
when I had a client who demanded it; I did have such a client; I
did work with it for several months; I did make everything work
that I needed to do (most of which was rather simple), but I was,
at best, UNDERwhelmed.

Oh, Larry, you've just got a bad attitude -- you don't have the
proper degree of hatred for Jet!

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

On Tue, 12 Apr 2005 20:28:31 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:6s********************************@4ax.com :

On Mon, 11 Apr 2005 20:21:28 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Susan Bricker <sl*****@verizon.net> wrote in
news:yI*************@news.uswest.net:

I hate to admit it, though, that I have exclusively used DAO in
the VBA behind forms and reports.

There's nothing to admit.

ADO is of virtually no use in an Access application manipulating
data stored in Jet databases (i.e., MDB files).

It is quite useful if you're back end is SQL Server.

Other than that, the ADO thing was a massive hoax perpetrated by
Microsoft's marketing department, i.e., people who didn't have any
comprehension whatsoever of the technical issues involved.

Oh, I give them a bit more credit than that. ADO was a
reasonable-seeming effort to unify the common aspects of how
persistent data is read/written to databases, file systems, etc.
It also included some genuine fixes to object model strangeness,
and some big improvements in handling stateless connections.

I only meant the way ADO was marketed in Access was a hoax.

Oh - yes, it was.

Still, if it had been a bit more stable, and if you could bind forms to
disconnected, batch-update recordsets that might or might not have originated
from MS SQL Server, that would have been truly compelling. It's as if they
managed to vault 19' 11", but the pole was at 20'.

[Lyle Fairfield]

Steve Jorgensen <no****@nospam.nospam> wrote in message news:<r8********************************@4ax.com>. ..

.... if you could bind forms to
disconnected, batch-update recordsets that might or might not have originated
from MS SQL Server, that would have been truly compelling.

I think this can be done?

[Steve Jorgensen]

On 13 Apr 2005 10:47:59 -0700, ly******@yahoo.ca (Lyle Fairfield) wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in message news:<r8********************************@4ax.com>. ..

.... if you could bind forms to
disconnected, batch-update recordsets that might or might not have originated
from MS SQL Server, that would have been truly compelling.

I think this can be done?

I tried it and got pretty far. Technically, it can sort of be done.

Unfortunately, the way the Access ADO driver on top of the MSSQL ADO driver
and the forms hook into the middle, mucking about with bits they shouldn't,
and being unaware that they might be bound to disconnected recordsets, they
completely mess it up.

First off, edits you make via the form modify the underlying value (which
should only ever be set by reading the back-end data) instead of the current
value, so the batch update has completely wrong information on what to do.

Second, Access keeps thinking it should reconnect to the back-end to do things
that have nothing to do with the back-end such as change the client-side
filter.

Third, eventually (usually pretty soon) Access crashes badly after trying to
do much with a recordset both from code and connected to a form.