DAO IS DED

[a a r o n . k e m p f]

http://msdn.microsoft.com/en-us/library/aa293439(VS.60).aspx
Further, DAO 3.x is not thread-safe. You should use DAO only in the
primary thread of an application.

http://msdn.microsoft.com/en-us/library/yb6xfda3.aspx
.NET, the Visual C++ environment and wizards no longer support DAO
(although the DAO classes are included and you can still use them)

http://support.microsoft.com/kb/325020
SUMMARY
This article points to the "Migrating from DAO and ODBCDirect to ADO"
white paper.
MORE INFORMATION
This white paper provides a migration path for users who want to use
ADO instead of Data Access Objects (DAO) and ODBCDirect to access SQL
Server or the Microsoft Data Engine (MSDE). The white paper briefly
describes ADO components and DAO and ODBCDirect components, and
compares the object models of these two technologies. It maps the
methods and properties of DAO and ODBCDirect to the methods of ADO,
and provides a guide for revising application code that uses DAO and
ODBCDirect technology to upgrade to ADO technology to connect to SQL
Server and MSDE database engines.

Data Access Objects (DAO) 3.5 technology provides two paths to access
Open Database Connectivity (ODBC) data sources. The first is through
the JET database engine,

which is not the most efficient way to deal with intelligent database
engines such as Microsoft® SQL Server™.
which is not the most efficient way to deal with intelligent database
engines such as Microsoft® SQL Server™.
which is not the most efficient way to deal with intelligent database
engines such as Microsoft® SQL Server™.

ODBCDirect is the second path that bypasses the JET database engine,
and provides direct access to the server by connecting through ODBC
application programming interface (API).
DAO permits users to consume only JET and ODBC data sources; however,
ADO provides a lot of flexibility to users to consume all OLE DB data
sources. As long as you have Microsoft OLE DB provider as a data
source, ADO connects and communicates with the server. Microsoft
provides several OLE DB providers through Microsoft Data Access
Components (MDAC) including OLE DB Provider for ODBC Drivers and OLE
DB Provider for SQL Server (SQLOLEDB). For additional information
about MDAC, visit the following Microsoft Web site:
http://www.microsoft.com/data/
You can also develop your own OLE DB providers for proprietary data
sources. ADO is designed to access and to work with data in a
relational database server and other non-relational data stores
through OLE DB providers.
ADO provides the following two methods to access a SQL Server
database:
The preferred method, is to use OLE DB Provider for SQL Server to
connect to the database from ADO. With this method, SQL Server exposes
significant native functionality that is based on the native OLE DB
Provider for SQL Server and provides users with faster and better
access.
Provider=MSDASQL.1;Persist Security Info=False;Data
Source=mytestDsn;Initial Catalog=Northwind
Notice the keyword Provider in the connection string. MSDASQL is not a
SQL Server Provider. It is an OLE DB Provider for ODBC DriversObject
Models.
The second method is to use OLE DB Provider for ODBC Drivers to
connect to the database. This method uses the SQL Server ODBC Driver.
The connection string looks similar to the following:
Moreover, ADO object model has fewer objects, but has more properties,
methods, and method arguments than DAO and ODBCDirect. ADO is thread-
safe, but DAO is not. Therefore, do not use DAO in Active Server Pages
(ASP) pages or in multithreaded applications.

Unlike DAO and ODBCDirect object model, ADO is less hierarchical, as
shown in Figure 2. You can create most of the objects in ADO without
calling a function on another object to generate the objects.

http://www.microsoft.com/communitie...22-9b64-fb19a01ffe88&cat=&lang=&cr=&sloc=&p=1
Always close DAO recordsets and set them to nothing before the end
of the
proc. ADO recordsets don't need to be closed before setting to
nothing.


http://msdn.microsoft.com/en-us/library/ms810810.aspx
Deprecated MDAC Components

These components are still supported in the current release of MDAC,
but they might be removed in future releases. Microsoft recommends,
when you develop new applications, that you avoid using these
components. Additionally, when you upgrade or modify existing
applications, remove any dependency on these components.

* Jet: Starting with version 2.6, MDAC no longer contains Jet
components. In other words, MDAC 2.6, 2.7, 2.8, and all future MDAC
releases do not contain Microsoft Jet, Microsoft Jet OLE DB Provider,
or the ODBC Desktop Database Drivers.
* JRO: The Microsoft Jet OLE DB Provider and other related
components have been removed from the MDAC stack since MDAC 2.6. Jet
Replication Objects (JRO) is used only with Jet (Access) databases—
basically, to create or compact the Jet Database and Jet Replication
Management. JRO has been deprecated, and MDAC 2.7 will be its last
release. It will not be available on the 64-bit Windows operating
system.

Obsolete Data Access Technologies

Obsolete technologies are technologies that have not been enhanced or
updated in several product releases and that will be excluded from
future product releases. Do not use these technologies when you write
new applications. When you modify existing applications that are
written by using these technologies, consider migrating those
applications to ADO.NET.

The following components are considered obsolete:

* Data Access Objects (DAO): DAO provides access to JET (Access)
databases. This API can be used from Microsoft Visual Basic, Microsoft
Visual C++, and scripting languages. It was included with Microsoft
Office 2000 and Office XP. DAO 3.6 is the final version of this
technology. It will not be available on the 64-bit Windows operating
system.

Current MDAC Components

These components are supported in the current release. Use these
components when you develop new applications or upgrade existing
applications.

* ADO: ActiveX Data Objects (ADO) provides a high-level
programming model that will continue to be enhanced. Although a little
less performance than coding to OLE DB or ODBC directly, ADO is
straightforward to learn and use, and it can be used from script
languages, such as Microsoft Visual Basic Scripting Edition (VBScript)
or Microsoft JScript.

http://msdn.microsoft.com/en-us/library/aa227260.aspx
Fun with Schemas

Remember when we wrote the Database Analyzer using DAO a while back?
This worked great, but on Access .mdb files only. However, what
happens if we are using an OLE DB data provider and we don't know
exactly what fields are available? Well, we can accomplish the same
thing for any data source as we did using out DAO Table Analyzer,
using ADO.

 

[Beetle]

"Insanity: Doing the same thing over and over again, and expecting
different results" - Albert Einstein

Hmmmmm. Seems like Albert must have been familiar with your posts, eh?

 

[Klatuu]

Warning to readers of this post.
aaron kemp is a known troll who has an obsesive dislike for Access. The
content of this post is not correct.

DAO is neither dead nor obsolete.
The current version is 4.0
Because ADO has issuesin Access, Microsoft returned to DAO as the default in
Access 2003.
mdb applications should use DAO. To use DAO successfully, adp should be used.

 

[BruceM]

"To use DAO successfully, adp should be used"

Did you reverse two letters there, or did I miss something?

 

[bcap]

I hear a scraping sound, I think it may be coming from the bottom of a
barrel!

I hope you wasted many hours digging up all that ancient history, Aaron.

 

[Troll Chaser]

Ah! I see that this pimple-faced fat-assed moron has turned from merely
nonsensical replies to posters who's questions bear no resemblance to his
answers. Now the scum-sucking idiot is starting his own threads.

Well WRONG AGAIN MORON!!!

The KB article that you quote is 6 years old. It is ADO that's dead (btw,
note the spelling), or dying, anyway, having been replaced by ADO.NET.
Further ADO.NET is not an extension of ADO, nor can ADO be easily upsized to
ADO.NET. Coding must be rewritten. Don't worry though, ADO will still be
supported, for a while, not that it will help you much. You have to be able
to at least walk and chew gum at the same time to use it.

When are you going to stop embarrassing yourself?

message
http://msdn.microsoft.com/en-us/library/aa293439(VS.60).aspx
Further, DAO 3.x is not thread-safe. You should use DAO only in the
primary thread of an application.

http://msdn.microsoft.com/en-us/library/yb6xfda3.aspx
..NET, the Visual C++ environment and wizards no longer support DAO
(although the DAO classes are included and you can still use them)

http://support.microsoft.com/kb/325020
SUMMARY
This article points to the "Migrating from DAO and ODBCDirect to ADO"
white paper.
MORE INFORMATION
This white paper provides a migration path for users who want to use
ADO instead of Data Access Objects (DAO) and ODBCDirect to access SQL
Server or the Microsoft Data Engine (MSDE). The white paper briefly
describes ADO components and DAO and ODBCDirect components, and
compares the object models of these two technologies. It maps the
methods and properties of DAO and ODBCDirect to the methods of ADO,
and provides a guide for revising application code that uses DAO and
ODBCDirect technology to upgrade to ADO technology to connect to SQL
Server and MSDE database engines.

Data Access Objects (DAO) 3.5 technology provides two paths to access
Open Database Connectivity (ODBC) data sources. The first is through
the JET database engine,

which is not the most efficient way to deal with intelligent database
engines such as Microsoft® SQL Server™.
which is not the most efficient way to deal with intelligent database
engines such as Microsoft® SQL Server™.
which is not the most efficient way to deal with intelligent database
engines such as Microsoft® SQL Server™.

ODBCDirect is the second path that bypasses the JET database engine,
and provides direct access to the server by connecting through ODBC
application programming interface (API).
DAO permits users to consume only JET and ODBC data sources; however,
ADO provides a lot of flexibility to users to consume all OLE DB data
sources. As long as you have Microsoft OLE DB provider as a data
source, ADO connects and communicates with the server. Microsoft
provides several OLE DB providers through Microsoft Data Access
Components (MDAC) including OLE DB Provider for ODBC Drivers and OLE
DB Provider for SQL Server (SQLOLEDB). For additional information
about MDAC, visit the following Microsoft Web site:
http://www.microsoft.com/data/
You can also develop your own OLE DB providers for proprietary data
sources. ADO is designed to access and to work with data in a
relational database server and other non-relational data stores
through OLE DB providers.
ADO provides the following two methods to access a SQL Server
database:
The preferred method, is to use OLE DB Provider for SQL Server to
connect to the database from ADO. With this method, SQL Server exposes
significant native functionality that is based on the native OLE DB
Provider for SQL Server and provides users with faster and better
access.
Provider=MSDASQL.1;Persist Security Info=False;Data
Source=mytestDsn;Initial Catalog=Northwind
Notice the keyword Provider in the connection string. MSDASQL is not a
SQL Server Provider. It is an OLE DB Provider for ODBC DriversObject
Models.
The second method is to use OLE DB Provider for ODBC Drivers to
connect to the database. This method uses the SQL Server ODBC Driver.
The connection string looks similar to the following:
Moreover, ADO object model has fewer objects, but has more properties,
methods, and method arguments than DAO and ODBCDirect. ADO is thread-
safe, but DAO is not. Therefore, do not use DAO in Active Server Pages
(ASP) pages or in multithreaded applications.

Unlike DAO and ODBCDirect object model, ADO is less hierarchical, as
shown in Figure 2. You can create most of the objects in ADO without
calling a function on another object to generate the objects.

http://www.microsoft.com/communitie...22-9b64-fb19a01ffe88&cat=&lang=&cr=&sloc=&p=1
Always close DAO recordsets and set them to nothing before the end
of the
proc. ADO recordsets don't need to be closed before setting to
nothing.


http://msdn.microsoft.com/en-us/library/ms810810.aspx
Deprecated MDAC Components

These components are still supported in the current release of MDAC,
but they might be removed in future releases. Microsoft recommends,
when you develop new applications, that you avoid using these
components. Additionally, when you upgrade or modify existing
applications, remove any dependency on these components.

* Jet: Starting with version 2.6, MDAC no longer contains Jet
components. In other words, MDAC 2.6, 2.7, 2.8, and all future MDAC
releases do not contain Microsoft Jet, Microsoft Jet OLE DB Provider,
or the ODBC Desktop Database Drivers.
* JRO: The Microsoft Jet OLE DB Provider and other related
components have been removed from the MDAC stack since MDAC 2.6. Jet
Replication Objects (JRO) is used only with Jet (Access) databases—
basically, to create or compact the Jet Database and Jet Replication
Management. JRO has been deprecated, and MDAC 2.7 will be its last
release. It will not be available on the 64-bit Windows operating
system.

Obsolete Data Access Technologies

Obsolete technologies are technologies that have not been enhanced or
updated in several product releases and that will be excluded from
future product releases. Do not use these technologies when you write
new applications. When you modify existing applications that are
written by using these technologies, consider migrating those
applications to ADO.NET.

The following components are considered obsolete:

* Data Access Objects (DAO): DAO provides access to JET (Access)
databases. This API can be used from Microsoft Visual Basic, Microsoft
Visual C++, and scripting languages. It was included with Microsoft
Office 2000 and Office XP. DAO 3.6 is the final version of this
technology. It will not be available on the 64-bit Windows operating
system.

Current MDAC Components

These components are supported in the current release. Use these
components when you develop new applications or upgrade existing
applications.

* ADO: ActiveX Data Objects (ADO) provides a high-level
programming model that will continue to be enhanced. Although a little
less performance than coding to OLE DB or ODBC directly, ADO is
straightforward to learn and use, and it can be used from script
languages, such as Microsoft Visual Basic Scripting Edition (VBScript)
or Microsoft JScript.

http://msdn.microsoft.com/en-us/library/aa227260.aspx
Fun with Schemas

Remember when we wrote the Database Analyzer using DAO a while back?
This worked great, but on Access .mdb files only. However, what
happens if we are using an OLE DB data provider and we don't know
exactly what fields are available? Well, we can accomplish the same
thing for any data source as we did using out DAO Table Analyzer,
using ADO.

 

[a a r o n . k e m p f]

ADO.net is great!!! and ADO is almost as good-- either way; DAO is
DOUBLE DEAD that doesn't bring it back to life

DAO doesnt' work against any database except JET.
which has a 2gb limit.

so now _WHAT_ do you really think that DAO is going to take over the
world?

there are ONE HUNDRED ADO users for every dao user-- out there in the
real world

 

[So Sorry For Poor Aaron]

:

:

Sad to say, aaron was oxygen-deprived as a fetus, and ever since birth his
family has been struggling to control his anger and consulting the best
neurologists and psychiartists in the land to try to raies his IQ to a
positive value. Unfortunately, both efforts have been without success, so
aaron keeps on posting information that is inapplicable to Access in Access
newsgroups, because he can't differentiate between "Access" and "SQL Server"
or because he hasn't the intelligence to scroll down the list to choose an
SQL Server newsgroup.

ADO.net is great!!! and ADO is almost as good--
either way; DAO is DOUBLE DEAD that doesn't
bring it back to life

See, the poor child cannot distinguish between ADO.NET and ADO, which share
only the three letters of the name... he does not realize that they are no
more alike than either of them is like DAO, which also shares the same three
letters, only in a different order.

DAO isn't dead at all... an enhanced version of DAO is used with the new
ACCDB database format, classic DAO was enhanced for Access 2007, classic ADO
only lives on for backward compatibility. So DAO isn't single dead, it isn't
double dead, it lives and thrives.

DAO doesnt' work against any database
except JET. which has a 2gb limit.

And, the poor boy is incapable of connecting thoughts. He just can't grasp
that DAO, through JET, plays nicely with ODBC, and that allows DAO and Jet to
integrate very well with any ODBC-compliant database (MS and Sybase SQL
Server, the free MySQL, the free PostgreSQL, the not-at-all-free Oracle,
Informix (what's left of it), other Sybase products, DB2, and others). He
just can't make that connection, mentally.

so now _WHAT_ do you really think that DAO
is going to take over the world?

And, even more sadly, it has left him with an overactive imagination and a
deficient memory. He imagines that someone other than himself has said
something about DAO taking over the world, or that it is remotely possible
for any database retrieval package to take over the world; and he forgets
that he's been reminded before that he is/was the only one ever to mention
such. Poor baby.

there are ONE HUNDRED ADO users for every dao
user-- out there in the real world

And, we should weep for him, here is another example... he imagines a
statistic and writes it as though it were researched, proven, and published.
He has, nor does anyone else, any idea of the ratio of users of ADO versus
DAO, and the new derivative of DAO for ACCDB. This sounds so good to him, and
supports his argument, so in his mind (overactive imagination) it just seems
true.

Please, join us in a moment of silence for aaron's brain, the brain that
never matured. If you are a believer, pray for healing for him, that he may
become a valued citizen and a contributor to society, instead of the outcast
pariah that he has made himself into. If you are not a believer, then hope
that some talented medical or psychological service provider will recognize
the dire situtaion in which aaron finds himself, step in, and work some magic
that will have the same result, to make aaron into a useful citizen and a
contributor rather than a disrupter.

So Sorry for Poor Aaron

 

[a a r o n . k e m p f]

ADO.net and ADO are actually a lot more alike then DAO.

with either, I use commands and TSQL DDL for almost everything I do..
with either, I use stored procedures for almost everything I do.

Just because DAO might be popular by a bunch of old blue-hairs out
here-- doesn't mean that it's the right choice for anyone-- or that
it's more popular in the larger VB6 population


I'm not a disrupter, I'm just trying to prove to others that Microsoft
_INSISTS_ that DAO IS DED.

 

[a a r o n . k e m p f]

ADO.net and ADO are actually a lot more alike then DAO.

with either, I use commands and TSQL DDL for almost everything I do..
with either, I use stored procedures for almost everything I do.

Just because DAO might be popular by a bunch of old blue-hairs out
here-- doesn't mean that it's the right choice for anyone-- or that
it's more popular in the larger VB6 population


I'm not a disrupter, I'm just trying to prove to others that Microsoft
_INSISTS_ that DAO IS DED.

 

[a a r o n . k e m p f]

re:
And, the poor boy is incapable of connecting thoughts. He just can't
grasp
that DAO, through JET, plays nicely with ODBC, and that allows DAO and
Jet to
integrate very well with any ODBC-compliant database (MS and Sybase
SQL
Server, the free MySQL, the free PostgreSQL, the not-at-all-free
Oracle,
Informix (what's left of it), other Sybase products, DB2, and
others). He
just can't make that connection, mentally.


SQL Server works EVEN BETTER than Jet does against these other
servers-- DTS is an enterprise level bridge for talking to other
database SERVERS.
and no-- DAO doesn't work for SHIT against SQL Server.

ADO is everywhere-- every .NET product in the whole wide world uses
either ADO classic or ADO.net
and ADO.net is quite similar to ADO.

DAO doesn't support anything involving OFFLINE RECORDSETS
DAO doesn't support working against _ANY_ database _EXCEPT_ through
jet.. I mean-- using SQL Server _THROUGH_ jet is just the biggest
waste of resources of all time.

THAT is one of the main reasons I choose to use ADP for a dozen large
corporations in the Seattle area.
_WHERE_APPROPRIATE_.

MOst importantly-- ADP is a great enviroment for writing VbScripts
that run in SQL Agent.
Does Jet support scheduled VB/VBA/VBS?

SQL Server can fire a vb file without any coding.

DAO hasn't been included BY DEFAULT in 3-4 versions of Office, MDAC
and Windows.
Just because MS realizes that the 'enemy of your enemy _MIGHT_ be your
friend'- that doesn't make DAO more efficient or effective for
anything.


can DAO even protect against SQL Injection?

Is it PHYSICALLY POSSIBLE that DAO can help to protect against SQL
Injection?
HELL NO.

 

[bcap]

ROTFLMAO!

message

 

[So Sorry For Poor Aaron]

ADO.net and ADO are actually a lot more alike then DAO.

Oh, how really said, the poor benighted child now cannot distinguish between
three "access methods" that are completely dissimilar. If he were as
competent with SQL Server as he has claimed, he would know better... no two
of the three even share the same object model. Their similarity ends with
"can access data" and "share the same three initials".

with either, I use commands and TSQL DDL
for almost everything I do.. with either, I use
stored procedures for almost everything I do.

Poor, poor aaron doesn't know whether he uses "commands and TSQL DDL" or
whether he uses "stored procedures". "DDL" is for creating database objects,
a task for which modern, up-to-date databases provide user interface for
doing and which no serious database developer does at runtime, except the
occasional temporary table. And, of course, in Access/Jet/ACE, there are
much, much easier, simpler, and more straightforward ways to create object
than DDL, in any case, even if one feels _compelled_ to not use the user
interface for doing so. Sadly aaron has just confessed that he's not a
database person who ought to be posting her, but a code monkey who tries to
dabble in database. But like many code monkeys, fails to grasp the concepts.
In fact, your local organ grinder's monkey likely knows more about database
than poor brain-challenged aaron does.

Just because DAO might be popular by a
bunch of old blue-hairs out here-- doesn't
mean that it's the right choice for anyone--
or that it's more popular in the larger
VB6 population

And, now the poor deluded little boy has somehow convinced himself that DAO
is in a "propularity contest" and that "the larger VB6 population" has
something to do with it. If he knew anything about the classic VB
population, he'd know that DAO was, and is, the native language of Jet and
that intelligent VB developers prefer DAO when they are dealing with Jet
databases as they often, very often, do. ADO was introduced in the classic VB
world very late in the game just as the Microsoft marketing mavens killed it
in favor of VB.NET (ADO came late, also, to Access/Jet party), was
dramatically overhyped by the Microsoft marketing mavens, who, being very
good at persuasion, convinced a small minority of people (most of whom knew
little about databases -- code monkeys) like aaron. Now that the greater
Microsoft developer support / tools community has moved on, poor aaron can
overload his brain and move along with them.

I'm not a disrupter, I'm just trying to prove
to others that Microsoft _INSISTS_ that
DAO IS DED.

And, the final blow to his own arguments -- the neurological marvel who
manages somehow to survive with a negative intelligence quotient annot
distinguish between himself and Microsoft, nor between proof and his own
bluff and bluster. And, of course, it would be asking far, far too much to
think that he could spell "dead"... it seems, with all his other mental
issues, he is "a-challenged", too.

Please take a few moments from your busy, productive schedule to think, to
encourage researchers, and, yes, even to pray for healing of one kind or
another for poor aaron that his IQ will raise to the positive and that he can
aspire to climb the learning ladder to idiocy. That will be such a great
improvment for him, should it be feasible, though it seems a dim hope when it
comes to aaron.

So Sorry For Poor Mentally-Challenged Aaron

P.S. There's a rumor that they were testing a mentality-enhancer machine on
aaron, and it flashed a bright light, filled the room with smoke, and
everyone ran out. But they could still see the IQ gauge which showed the
malfunction had, in fact, reduced his IQ even much lower that it had been,
and it was already negative.

 

[So Sorry For Poor Aaron]

I'm not a disrupter,

Thanks for saying at least one thing that'll leave us all chuckling, aaron.

<SNNNRRRCH>

 

[a a r o n . k e m p f]

SQL Server is just a better engine.

ADP is such a better experience for the people USING your database.
ADP is such a better experience for the people USING your database.
ADP is such a better experience for the people USING your database.
ADP is such a better experience for the people USING your database.

 

[a a r o n . k e m p f]

what, you don't write CREATE INDEX statements?

MUCH faster to write 10 create index statements than to go through the
GUI, let me tell you that!!!

 

[James A. Fortune]

http://msdn.microsoft.com/en-us/library/aa293439(VS.60).aspx
Further, DAO 3.x is not thread-safe. You should use DAO only in the
primary thread of an application.

http://msdn.microsoft.com/en-us/library/yb6xfda3.aspx
.NET, the Visual C++ environment and wizards no longer support DAO
(although the DAO classes are included and you can still use them)

http://support.microsoft.com/kb/325020
SUMMARY
This article points to the "Migrating from DAO and ODBCDirect to ADO"
white paper.
MORE INFORMATION
This white paper provides a migration path for users who want to use
ADO instead of Data Access Objects (DAO) and ODBCDirect to access SQL
Server or the Microsoft Data Engine (MSDE). The white paper briefly
describes ADO components and DAO and ODBCDirect components, and
compares the object models of these two technologies. It maps the
methods and properties of DAO and ODBCDirect to the methods of ADO,
and provides a guide for revising application code that uses DAO and
ODBCDirect technology to upgrade to ADO technology to connect to SQL
Server and MSDE database engines.

Data Access Objects (DAO) 3.5 technology provides two paths to access
Open Database Connectivity (ODBC) data sources. The first is through
the JET database engine,

which is not the most efficient way to deal with intelligent database
engines such as Microsoft® SQL Server™.
which is not the most efficient way to deal with intelligent database
engines such as Microsoft® SQL Server™.
which is not the most efficient way to deal with intelligent database
engines such as Microsoft® SQL Server™.

ODBCDirect is the second path that bypasses the JET database engine,
and provides direct access to the server by connecting through ODBC
application programming interface (API).
DAO permits users to consume only JET and ODBC data sources; however,
ADO provides a lot of flexibility to users to consume all OLE DB data
sources. As long as you have Microsoft OLE DB provider as a data
source, ADO connects and communicates with the server. Microsoft
provides several OLE DB providers through Microsoft Data Access
Components (MDAC) including OLE DB Provider for ODBC Drivers and OLE
DB Provider for SQL Server (SQLOLEDB). For additional information
about MDAC, visit the following Microsoft Web site:
http://www.microsoft.com/data/
You can also develop your own OLE DB providers for proprietary data
sources. ADO is designed to access and to work with data in a
relational database server and other non-relational data stores
through OLE DB providers.
ADO provides the following two methods to access a SQL Server
database:
The preferred method, is to use OLE DB Provider for SQL Server to
connect to the database from ADO. With this method, SQL Server exposes
significant native functionality that is based on the native OLE DB
Provider for SQL Server and provides users with faster and better
access.
Provider=MSDASQL.1;Persist Security Info=False;Data
Source=mytestDsn;Initial Catalog=Northwind
Notice the keyword Provider in the connection string. MSDASQL is not a
SQL Server Provider. It is an OLE DB Provider for ODBC DriversObject
Models.
The second method is to use OLE DB Provider for ODBC Drivers to
connect to the database. This method uses the SQL Server ODBC Driver.
The connection string looks similar to the following:
Moreover, ADO object model has fewer objects, but has more properties,
methods, and method arguments than DAO and ODBCDirect. ADO is thread-
safe, but DAO is not. Therefore, do not use DAO in Active Server Pages
(ASP) pages or in multithreaded applications.

Unlike DAO and ODBCDirect object model, ADO is less hierarchical, as
shown in Figure 2. You can create most of the objects in ADO without
calling a function on another object to generate the objects.

http://www.microsoft.com/communitie...22-9b64-fb19a01ffe88&cat=&lang=&cr=&sloc=&p=1
Always close DAO recordsets and set them to nothing before the end
of the
proc. ADO recordsets don't need to be closed before setting to
nothing.


http://msdn.microsoft.com/en-us/library/ms810810.aspx
Deprecated MDAC Components

These components are still supported in the current release of MDAC,
but they might be removed in future releases. Microsoft recommends,
when you develop new applications, that you avoid using these
components. Additionally, when you upgrade or modify existing
applications, remove any dependency on these components.

* Jet: Starting with version 2.6, MDAC no longer contains Jet
components. In other words, MDAC 2.6, 2.7, 2.8, and all future MDAC
releases do not contain Microsoft Jet, Microsoft Jet OLE DB Provider,
or the ODBC Desktop Database Drivers.
* JRO: The Microsoft Jet OLE DB Provider and other related
components have been removed from the MDAC stack since MDAC 2.6. Jet
Replication Objects (JRO) is used only with Jet (Access) databases—
basically, to create or compact the Jet Database and Jet Replication
Management. JRO has been deprecated, and MDAC 2.7 will be its last
release. It will not be available on the 64-bit Windows operating
system.

Obsolete Data Access Technologies

Obsolete technologies are technologies that have not been enhanced or
updated in several product releases and that will be excluded from
future product releases. Do not use these technologies when you write
new applications. When you modify existing applications that are
written by using these technologies, consider migrating those
applications to ADO.NET.

The following components are considered obsolete:

* Data Access Objects (DAO): DAO provides access to JET (Access)
databases. This API can be used from Microsoft Visual Basic, Microsoft
Visual C++, and scripting languages. It was included with Microsoft
Office 2000 and Office XP. DAO 3.6 is the final version of this
technology. It will not be available on the 64-bit Windows operating
system.

Current MDAC Components

These components are supported in the current release. Use these
components when you develop new applications or upgrade existing
applications.

* ADO: ActiveX Data Objects (ADO) provides a high-level
programming model that will continue to be enhanced. Although a little
less performance than coding to OLE DB or ODBC directly, ADO is
straightforward to learn and use, and it can be used from script
languages, such as Microsoft Visual Basic Scripting Edition (VBScript)
or Microsoft JScript.

http://msdn.microsoft.com/en-us/library/aa227260.aspx
Fun with Schemas

Remember when we wrote the Database Analyzer using DAO a while back?
This worked great, but on Access .mdb files only. However, what
happens if we are using an OLE DB data provider and we don't know
exactly what fields are available? Well, we can accomplish the same
thing for any data source as we did using out DAO Table Analyzer,
using ADO.

Aaron,

I must commend you for trying to find actual references to support your
case. I haven't seen much of that from you before so I take that as a
positive sign. Most of us in this NG were prematurely fooled into
believing that ADO was on its way in and that DAO was on its way out. I
even took on an ASP project back in 2000 so that I would be ready for
ADODB when it replaced DAO. I even managed the SQL Server data using an
ADP. In the meantime, I was still doing most of my Access development
in DAO expecting that I would have to change over to ADO when Microsoft
perfected it. Microsoft has taught us the hard way not to change what
we are doing without a good reason. Given such a situation, providing
actual reasons for making changes that are backed up with cogent
reasoning go a long way in persuading Access professionals to make
changes. Most of your reasons have been weak, but not nonexistent.
Your arguments have been less than cogent. But I encourage you to
continue to try to provide good reasons along with appropriate links to
references. Then you might start some serious discussion about when a
switch to SQL Server as a backend is most appropriate.

James A. Fortune
(e-mail address removed)

 

[a a r o n . k e m p f]

this:
Microsoft has taught us the hard way not to change what
we are doing without a good reason.

MEANS STAY WITH ADO

Changing back to DAO makes no sense to me.

I have never had a weak or non-existent reason. On this channel there
are dozens of dipshits giving mis-information about SQL Server.
Jet corrupts and anyone that uses it is short-sighted

Case closed.

SQL Sever is _ALWAYS_ appropriate for applications of all size.

I am faster with ADP than anyone here with MDB. GUARANTEE it.

I build it NICE instead of build it TWICE.

There is no such thing as a business case for Jet; and there hasn't
been -- ever since SQL Server became free at the low end.

-Aaron

 

[a a r o n . k e m p f]

ADO actually is more similiar to ADO.net.. because of several simple
concepts:

a) it works against _ANY_ engine. Not just Jet.
b) it has been widely adopted throughout the industry
c) ADO is more flexible- you don't need to always create object 1,2,3
in order to get to 4.
same with ADO.net

DAO is just plain stupid.
It ties you to a single worthless db engine.

If your engine corrupts-- _EVER_ and your DAL forces you to that one
engine-- it's time for a new DAL _AND_ a new database engine.
If your engine corrupts-- _EVER_ and your DAL forces you to that one
engine-- it's time for a new DAL _AND_ a new database engine.
If your engine corrupts-- _EVER_ and your DAL forces you to that one
engine-- it's time for a new DAL _AND_ a new database engine.