By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,456 Members | 1,250 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,456 IT Pros & Developers. It's quick & easy.

ADO.NET is an evolution of the ADO data access model

P: n/a
http://samples.gotdotnet.com/QuickSt...sOverview.aspx

**** begin quote ****
ADO.NET Overview
ADO.NET is an evolution of the ADO data access model that directly
addresses user requirements for developing scalable applications. It
was designed specifically for the web with scalability, statelessness,
and XML in mind.

ADO.NET uses some ADO objects, such as the Connection and Command
objects, and also introduces new objects. Key new ADO.NET objects
include the DataSet, DataReader, and DataAdapter.

The important distinction between this evolved stage of ADO.NET and
previous data architectures is that there exists an object -- the
DataSet -- that is separate and distinct from any data stores. Because
of that, the DataSet functions as a standalone entity. You can think of
the DataSet as an always disconnected recordset that knows nothing
about the source or destination of the data it contains. Inside a
DataSet, much like in a database, there are tables, columns,
relationships, constraints, views, and so forth.
**** end quote ****

The site has more information.

May 23 '06 #1
Share this Question
Share on Google+
9 Replies


P: n/a
On 22 May 2006 19:26:00 -0700, "Lyle Fairfield"
<ly***********@aim.com> wrote:

You forgot to mention you're 4 years late with this information, and
it is also off-topic, no?

-Tom.
http://samples.gotdotnet.com/QuickSt...sOverview.aspx

**** begin quote ****
ADO.NET Overview
ADO.NET is an evolution of the ADO data access model that directly
addresses user requirements for developing scalable applications. It
was designed specifically for the web with scalability, statelessness,
and XML in mind.

ADO.NET uses some ADO objects, such as the Connection and Command
objects, and also introduces new objects. Key new ADO.NET objects
include the DataSet, DataReader, and DataAdapter.

The important distinction between this evolved stage of ADO.NET and
previous data architectures is that there exists an object -- the
DataSet -- that is separate and distinct from any data stores. Because
of that, the DataSet functions as a standalone entity. You can think of
the DataSet as an always disconnected recordset that knows nothing
about the source or destination of the data it contains. Inside a
DataSet, much like in a database, there are tables, columns,
relationships, constraints, views, and so forth.
**** end quote ****

The site has more information.


May 23 '06 #2

P: n/a
"Lyle Fairfield" <ly***********@aim.com> wrote
**** begin quote ****
ADO.NET Overview
ADO.NET is an evolution of the ADO data access model that directly
addresses user requirements for developing scalable applications. It
was designed specifically for the web with scalability, statelessness,
and XML in mind.


Troll all you want, Lyle, you aren't going to catch an argument from me.

Marketeers will tell you anything. :-)

It's so evolved that it doesn't use OLEDB as a matter of course, though you
can lay some ADO.NET classes over OLEDB, but, if I remember correctly, you
can lay ADO.NET classes over ODBC, too.

Larry

May 26 '06 #3

P: n/a
After thinking about this for a few days I am still of the opinion that
my post is pertinent to MS-Access.

Only three months ago Access MVPs posted these comments here in CDMA:

**** quote one (Allen Browne) ****
Microsoft was pushing ADO about 5 years ago, as a more generic library
(suitable for things wider than Access), but it is now dead, replaced
by the
very different ADO.NET. There is therefore now no point in doing this
just
to learn ADO, no point at all in doing it for an Access application,
and no
point at all at all in doing it for an existing Access application.
**** end quote one ****

**** quote two (Larry Linson) ****
Have not the "knowledgeable 'Softie insiders" blogged that the Access
development team has taken over what used to be called Jet and what
used to
be called DAO, for additional development in the next version
(apparently
now officially named Office 2007)?

Perhaps they are also enhancing "classic ADO" for Office 2007. Can you
provide a reference to a statement that they are?
**** end quote two ****

Until shortly before I posted the original post in this thread I was
unaware that MS stated explicitly,
"ADO.NET is an evolution of the ADO data access model"
and until your post I was unaware that this site's content was four
years old.

Clearly the site contradicts Allen Browne's assertion. If the site's
statement is wrong I would be pleased to learn how and why. If it's
not, I may say, Tom, that I am disappointed that you did not bring it
to our attention earlier, as I infer from your post that you have known
about this for a long time and, it's been my observation that you are
one the most thorough, capable and fair regular CDMA posters.

I thought and still think that the site may be helpful for those Access
developers who are agonizing about Access 2007, Ace and the .Net
technologies.

I am sorry that I did not become familiar with it as early as you did.

May 26 '06 #4

P: n/a
Larry

You have a great background in coding, programming, developing,
databases etc, longer and more comprehensive than mine, and you often
share insights which others without your experience could not have. You
probably have no idea how someone like me could envy your lifetime of
involvement with computers and programming. Fortunately, God did not
say, "Thou shall not covet thy neighbours experience with IBM!"

But IMO you just don't understand this issue.

A few months ago you made this comment:

[Perhaps they are also enhancing "classic ADO" for Office 2007.]

As long as Office 97's VBA is COM based it can always use the current
version of ADO.

Bigger questions, for me are, "Will there be an ADO provider for
ACE?" (and perhaps this is what you meant). I doubt it as ACE is,
reportedly, for Access only, so what would the purpose of such a
Provider be. But I have no idea what the right answer to this may be.
Will ACE actually be the preferred database engine/technology for
Access as the blogs suggest, or will we find that it's just there as
a stop gap, while we are conditioned to using SQL Express? There is an
ADO provider for SQL Express of course.

I could be studying this now I suppose but became so POed with 2007
BETA and expunged it from my machine.

May 26 '06 #5

P: n/a
"Lyle Fairfield" <ly***********@aim.com> wrote
You have a great background in coding, programming, developing,
databases etc, longer and more comprehensive than mine, and you often
share insights which others without your experience could not have. You
probably have no idea how someone like me could envy your lifetime of
involvement with computers and programming. Fortunately, God did not
say, "Thou shall not covet thy neighbours experience with IBM!"
Thanks for the kind words. There are times when I think about it, I wish I
could trade some of that experience for some memories of missing parts of my
children's growing-up.
But IMO you just don't understand this issue.

A few months ago you made this comment:

[Perhaps they are also enhancing "classic ADO" for Office 2007.]
I meant "enhancing it to use any features added to ACE" that aren't in the
lowly MDB.
As long as Office 97's VBA is COM based it can always use the current
version of ADO.
Hunh? How did O97 get into the discussion? Given that it did, I believe you
are right that I just don't understand.
Bigger questions, for me are, "Will there be an ADO provider for
ACE?" (and perhaps this is what you meant). I doubt it as ACE is,
reportedly, for Access only, so what would the purpose of such a
Provider be. But I have no idea what the right answer to this may be.
Will ACE actually be the preferred database engine/technology for
Access as the blogs suggest, or will we find that it's just there as
a stop gap, while we are conditioned to using SQL Express? There is an
ADO provider for SQL Express of course.
I don't know the answer (and it's not a matter of "I know it under NDA so
can't tell"... I really don't know). It would not surprise me if they
enhanced ADO to accomodate ACE; but it wouldn't surprise me if they gave us
a "flavor" of ADO.NET, instead.
I could be studying this now I suppose but became so POed with 2007
BETA and expunged it from my machine.


I don't have a separate machine on which to install the beta, and am not
sure that implementing a VM on the notebook that I use would be feasible, so
I have not experimented with Office 2007. I am just relying on the blogged
and published information. So far, it appears to me that the emphasis is on
collaboration in a large-company environment. But, at present, none of my
clients, even relatively large ones are using any version of Share Point.

Larry Linson
Microsoft Access MVP
May 26 '06 #6

P: n/a
Larry Linson wrote:
> As long as Office 97's VBA is COM based it can always use the current
> version of ADO.


Hunh? How did O97 get into the discussion? Given that it did, I believe you
are right that I just don't understand.


I meant 2007.

May 26 '06 #7

P: n/a
Well Larry I reinstalled the Beta and after a very short period of
experimentation I can report that it !!!!!SEEMS!!!!!:

DAO is alive and well and living in Access 2007 (12 or whatever).

So is ADO.

There does not seem to be a default reference to either but they're
there or clones are. It seems JET may still be used for security.
(Remember early Windows versions where DOS hung around?).

The CurrentProject.Connection is an ADO connection or is so similar
that we can set an object dimmed as an ADODB connection to the
CurrentProject.Connection.

There is a new ADODB provider for ACE which is used inside the 2007 db
and can be used outside the db in other technologies to access the ACE
data in the db.

May 26 '06 #8

P: n/a
"Lyle Fairfield" <ly***********@aim.com> wrote in
news:11**********************@j55g2000cwa.googlegr oups.com:
Bigger questions, for me are, "Will there be an ADO provider for
ACE?" (and perhaps this is what you meant). I doubt it as ACE is,
reportedly, for Access only, so what would the purpose of such a
Provider be. . . .
Er, why would you store data in a data format that couldn't be
accessed by anything but the application that created it? That is,
if you've got data stored in the new Access data format, you'll want
to use it for merge from Word, and you'll want to use it to drive
that web page on your Intranet, and so forth.
. . . But I have no idea what the right answer to this may be.
Will ACE actually be the preferred database engine/technology for
Access as the blogs suggest, or will we find that it's just there
as a stop gap, while we are conditioned to using SQL Express?
There is an ADO provider for SQL Express of course.


Why in the world would the Access team fork the Jet database engine
for a stopgap means? It seems to me that the forking (which is
something you never want to do except if there's a really big
benefit in doing so), indicates that the Access team is really
dedicated to having its own native data engine, and one that *they*
have control over. To me, this represents an *increase* in emphasis
on Jet as a data store, rather than the beginning of a phasing out
of it.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
May 26 '06 #9

P: n/a
"Lyle Fairfield" <ly***********@aim.com> wrote in
news:11**********************@j55g2000cwa.googlegr oups.com:
Bigger questions, for me are, "Will there be an ADO provider for
ACE?" (and perhaps this is what you meant). I doubt it as ACE is,
reportedly, for Access only, so what would the purpose of such a
Provider be.


OK, I realize from reading Larry's reply that I misunderstood the
question. You were asking about classic ADO. I think that the answer
depends on how long Access uses classic ADO as its alternative data
access interface. As long as Access is wired to classic ADO, it will
have to be revised to work with revisions to the Jet db engine.

Or, so it seems to me.

The alternative would be to revise DAO only, and leave classic ADO
only for backward compatibility. I would hope that DAO *will* be
revised to work with the new format, but I wouldn't hold my breath.

Or, of course, abandoning classic ADO for ADO.NET, but we know
that's not going to happen.

Microsoft has made themselves a mess, I would say, but it's their
own fault for letting outside agendas drive the design of a product
with internal logic of its own that did fit well with the outside
agenda.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
May 26 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.