ADO 6

  • Thread starter Thread starter aaron.kempf
  • Start date Start date
A

aaron.kempf

So has anyone mentioned that Vista includes ADO 6.0?

Everyone has been talking about this DAO revival; I find it kinda funny
when it looks like there is an ADO revival also
 
So has anyone mentioned that Vista includes ADO 6.0?

Everyone has been talking about this DAO revival; I find it kinda funny
when it looks like there is an ADO revival also
Click to expand...

ADO History
http://windowssdk.msdn.microsoft.com/en-us/library/ms676506.aspx

"ADO 6.0 is functionally equivalent to ADO 2.8."

Without a new Jet OLE DB provider or indeed a revised Jet engine, I
don't think ADO 6.0 represents an ADO revival. FWIW I don't think DAO
will be ready to replace ADO for a few Access versions yet, certainly
not for Access2007.

Jamie.

--
 
Jamie Collins said:
ADO History
http://windowssdk.msdn.microsoft.com/en-us/library/ms676506.aspx

"ADO 6.0 is functionally equivalent to ADO 2.8."

Without a new Jet OLE DB provider or indeed a revised Jet engine, I
don't think ADO 6.0 represents an ADO revival. FWIW I don't think DAO
will be ready to replace ADO for a few Access versions yet, certainly
not for Access2007.
Click to expand...

Did you mean to write "... I don't think *ADO* will be ready to replace
*DAO* for a few Access versions yet, ..."?

There is more 'marketing' in "ADO 6" than technical differences. Since WinXP
and Win2003 there has been a shift from MDAC being a 'universal' update to
'platform specific' packages. Also M$ is moving away from vendors installed
upgrades and redistributable components.

Changing the package MDAC to DAC (Windows Data Access Components) is merely
the finalization of this migration for data access. DACs will be specific to
each O/S and upgradeable only as part of a MS SP for the O/S. There will not
be a separate DAC install. Each O/S will have its own set of DACs.

The "6" is actually the DAC version and doesn't reference the actual ADO
version included. Why they started with 6 is another MS mystery. They did
the same with VC++/VB when VB 5.1 <g> and VC++ 4 <?> suddenly all became VS
6. Perhaps from "666"? <g>

-ralph
 
Ralph said:
Did you mean to write "... I don't think *ADO* will be ready to replace
*DAO* for a few Access versions yet, ..."?
Click to expand...

No.

As already pointed out, ADO functionality has not been changed, hasn't
for several years.

Access development has moved away from Jet in favour of a dedicated
Access2007 engine. DAO seems to have been resurrected as Microsoft
Office 2007 Access database engine Object Library (ACEDAO.DLL).

Jamie.

--
 
Jamie Collins said:
No.

As already pointed out, ADO functionality has not been changed, hasn't
for several years.

Access development has moved away from Jet in favour of a dedicated
Access2007 engine. DAO seems to have been resurrected as Microsoft
Office 2007 Access database engine Object Library (ACEDAO.DLL).

Jamie.
Click to expand...

It looks like we have slightly different view of what "replacing" means. DAO
for Jet has always been (within a set of conditions) faster and more stable
than ADO. It still is with the new ADE.

So in light of your leading sentence - "Without a new Jet OLE DB provider or
indeed a revised Jet engine, I don't think ADO 6.0 represents an ADO
revival." Which is true. "ADO 6" is a misnomer and the jury is still out on
what a "ADE OLE DB" might bring to the table. Thus it stands to reason that
*DAO* is in no danger of being replaced, not the other way around.

Your comment "Access development has moved away from Jet in favor of a
dedicated Access2007 engine." is a bit misleading as the ADE in no way
represents an abandonment of "JET". It is more accurately described as a
branch or fork, and more represents the move in development and support from
the SQL Team to the Office Team, than in any fundamental core changes. It is
however, 'dedicated' in the sense that you cannot use the new features
without MSAccess/Office installed or without the new ADEDAO. They didn't
'resurrected' DAO, they expanded it.

And before anyone else reading this thread starts to panic. The ADE still
supports "Jet 4" - all your previous DAO and ADO will still work. The only
thing that seems to have changed is you can't use ADE independently of
MSAccess being installed, and you can't access any new functionality.
Exactly what all this means to future development is yet to fully unfold (Or
at least to me anyway. <g>)

-ralph
 
because of 'Windows 6.0 = VIsta' and Vienna = 6.1

notice the VI as in the roman numeral 6

4.0 = nt4
5.0 = 2000
5.1 = 2002 (XP - gag)
5.2 = 2003
6.0 = vista
 
im not sure that I agree with this:

It looks like we have slightly different view of what "replacing"
means. DAO
for Jet has always been (within a set of conditions) faster and more
stable
than ADO. It still is with the new ADE.


are you talking about execution time or development time?

surely developing solutions using DAO is ridiculous because it's nearly
impossible to switch from SQL to Access to Oracle; etc
 
I just still find it humorous

why don't they relaunch Windows 95 while they're at it?
 
because of 'Windows 6.0 = VIsta' and Vienna = 6.1

notice the VI as in the roman numeral 6

4.0 = nt4
5.0 = 2000
5.1 = 2002 (XP - gag)
5.2 = 2003
6.0 = vista
Click to expand...
<snipped>

That's interesting.

-ralph
 
"Access development has moved away from Jet in favor of a ACCESS DATA
PROJECTS"

this JET / DAO _CRAP_ that you kids talk about is laughable

DAO wasn't included in a couple of version of Windows and MDAC.. right?
it wasn't included in 2 versions of Office.

I dont believe that it is FAIR for Microsoft to pull a GOTCHA like
this.
you don't run around and keep on SHITTING on vb6 developers.

**** YOU MICROSOFT
 
im not sure that I agree with this:

It looks like we have slightly different view of what "replacing"
means. DAO
for Jet has always been (within a set of conditions) faster and more
stable
than ADO. It still is with the new ADE.


are you talking about execution time or development time?

surely developing solutions using DAO is ridiculous because it's nearly
impossible to switch from SQL to Access to Oracle; etc
Click to expand...
<snipped>

I'm talking about performance. In situations where OLE/COM is not a factor
(as simple client/server on the same box), or one doesn't need a particular
ADO feature, or one doesn't have multiple users/connections, DAO is the
better access library. Always has been.

The reason is simple, DAO was totally engineered with the Jet/ODBC in mind.
Or the Jet was designed with DAO in mind <g> - both are children of the same
technology wave. They work well together. DAO also works well with other
"ODBC" engines (AS/4000, DB2 for example).

Now whether it is 'ridiculous' or not is purely a matter of your problem
domain. Trade-offs between 'universality' or 'specialization' are always
with us. If one was designing an application that can pick and choose its
backend database - ADO perhaps does make more sense. That's exactly what it
was designed for. But the vast majority of applications don't offer or need
that kind of flexibility.

Also you might be surprised to learn that toggling between MSAccess,
SQLServer, and Oracle is not so difficult to do with DAO either.

FWIW, I always grab ADO as my first tool and only migrate to DAO when it
appears useful to do so. And last, with today's boxes, you have to work with
large recordsets, or come up with some rather contrieved scenarios before
you would notice a 'practical' difference between the two.

-ralph
 
you're full of it.

DAO has never been the better fit.
I can do anything in you can in ADO that you can in DAO.

what.. create a table?

CREATE TABLE TblName

what.. list the queries?

Select name from sysobjects where xtype in ('v', 'p')

what.. create an index?

what can your horseshit ass library do that mine cant'

Eat shit MDB wimp
DAO is DED

And it's unfair for Microsoft to change their minds just because a
couple of fat lazy retards are too stupid to learn SQL Server

-Aaron
 
I just disagree-- MILITANTLY-- with Microsoft changing directions on
this.

DAO is DEAD.
you can't even get decent error handling messages out of it.. can you?

When you get a SQL Server Error does DAO even return this to VB?


DAO is a piece of shit ass language
and so is MDB

and anyone that uses EITHER in the year 2006 should be spit on and
fired.

-Aaron
ADP Nationalist
 
shit; there are HANGS when you use DAO in MDB

why in the hell would we trust it with a REAL DATABASE?

DAO is DED and anyone else that says differently should get your ass
kicked
 
you're full of it.

DAO has never been the better fit.
I can do anything in you can in ADO that you can in DAO.

what.. create a table?

CREATE TABLE TblName

what.. list the queries?

Select name from sysobjects where xtype in ('v', 'p')

what.. create an index?

what can your horseshit ass library do that mine cant'

Eat shit MDB wimp
DAO is DED

And it's unfair for Microsoft to change their minds just because a
couple of fat lazy retards are too stupid to learn SQL Server

-Aaron
Click to expand...
<snipped>

I don't believe I said that DAO had some functional superiority over ADO.

However, I can understand that those who form an emotional attachment to one
particular technology may be sensitive to any suggestion that another
technology may offer an advantage in some areas. Thus imagining a slight
were none was given.

-ralph
 
I disagree; there are definitely reasons NOT to use DAO against SQL
Server
Click to expand...
<snipped>

Again I fail to see where I ever suggested using DAO with SQL Server.
Perhaps you are unaware of what the "Jet" is?

-ralph
 
well it's either performance or functionality; I don't buy the
performance benefits of DAO; and I sure don't buy the functionality.

'just because it's the old way to do things and were too lazy to
change' isn't a valid argument because Microsoft has waffled on this
for 10 years and now they can't just revive-- they can't retract
everything that they've said over the past 10 years.

Do you know how many clients i've sold DAO rewrites to?

It makes me look like crap; and im not going to stand for it.

DAO is flaky; it gives hangs; it gives unpredictable results.
And it doesn't always raise an error when a query fails.

ADO and SQL Server don't have problems like that
 
what.. like you update against a RECORDSET?


ROFL

you should update with Sql statements; kid

-Aaron
 
Back
Top