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*****@verizo n.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*****@verizo n.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...ADoxDDBOB O that
is worth switching for.

-dp

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

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*****@verizo n.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*****@veriz on.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*****@verizo n.net> wrote in
news:yI******** *****@news.uswe st.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*****@verizo n.net> wrote in
news:8u******** *******@news.us west.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********@bwa y.net.invalid> wrote:

Susan Bricker <sl*****@verizo n.net> wrote in
news:yI******* ******@news.usw est.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
comprehensio n 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*****@verizo n.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 ***