Re: Where did ADOX go? [X-posted]

A better choice would be to use DAO, which is the best choice when
working with Jet. Microsoft released a PIA for DAO, not ADOX, so they
must also agree -- you can get more info from
http://msdn.microsoft.com/library/d...odc_oxppias.asp.

-- Mary
MCW Technologies
http://www.mcwtech.com

On Fri, 27 Jun 2003 23:23:44 -0700, "Bob Bedell" <bobbedell15@msn.com>
wrote:

>Is there an ADO.NET replacement for ADOX. For example,
>used to be able create a new Jet database with:
>
>Sub ADOCreateDatabase()
> Dim cat As New ADOX.Catalog
> cat.Create "Provider=Microsoft.Jet.OLEDB.4.0;" & _
> "Data Source=C:\TestADOX.mdb;"
>End Sub
>
>How does ADO.NET do that?
>
>Thanks,
>
>Bob

On Sun, 29 Jun 2003 15:47:16 -0400, Mary Chipman <mchip@nomail.please> wrote:

¤ A better choice would be to use DAO, which is the best choice when
¤ working with Jet. Microsoft released a PIA for DAO, not ADOX, so they
¤ must also agree -- you can get more info from
¤ http://msdn.microsoft.com/library/d...odc_oxppias.asp.
¤
¤ -- Mary
¤ MCW Technologies
¤ http://www.mcwtech.com

Microsoft's VB Code Advisor indicates that DAO has been deprecated as of VB 6.0. Conversion to ADO
is recommended.


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

On Wed, 02 Jul 2003 10:02:33 -0500, Paul Clement
<UseAdddressAtEndofMessage@swspectrum.com> wrote:

>Microsoft's VB Code Advisor indicates that DAO has been deprecated as of VB 6.0. Conversion to ADO
>is recommended.

For VB6, maybe. For .NET, no, that's just wrong. When working
exclusively with the Jet Engine, DAO has always been the best choice.
It's faster and posseses full functionality. ADO is a more general
purpose API, and ADOX sucks bigtime against Jet, being buggy, slow,
and lacking functionality present in DAO.

Anyway, if DAO is so deprecated, then why did msft go to all the
trouble to create a PIA for it? I can understand DAO being deprecated
for data access where you really want to use ADO.NET, but not for DDL
tasks like create table. I think you can write off the Code Advisor
advice as uninformed--why would anyone want to convert any code in a
..NET app to ADO? That makes no sense at all. Conversion to ADO.NET
would be the recommended choice for data access, but you can't use it
to create tables, etc.

-- Mary
MCW Technologies
http://www.mcwtech.com

On Wed, 02 Jul 2003 18:33:22 -0400, Mary Chipman <mchip@nomail.please> wrote:

¤ On Wed, 02 Jul 2003 10:02:33 -0500, Paul Clement
¤ <UseAdddressAtEndofMessage@swspectrum.com> wrote:
¤
¤ >Microsoft's VB Code Advisor indicates that DAO has been deprecated as of VB 6.0. Conversion to ADO
¤ >is recommended.
¤
¤ For VB6, maybe. For .NET, no, that's just wrong. When working
¤ exclusively with the Jet Engine, DAO has always been the best choice.
¤ It's faster and posseses full functionality. ADO is a more general
¤ purpose API, and ADOX sucks bigtime against Jet, being buggy, slow,
¤ and lacking functionality present in DAO.
¤
¤ Anyway, if DAO is so deprecated, then why did msft go to all the
¤ trouble to create a PIA for it? I can understand DAO being deprecated
¤ for data access where you really want to use ADO.NET, but not for DDL
¤ tasks like create table. I think you can write off the Code Advisor
¤ advice as uninformed--why would anyone want to convert any code in a
¤ .NET app to ADO? That makes no sense at all. Conversion to ADO.NET
¤ would be the recommended choice for data access, but you can't use it
¤ to create tables, etc.

The primary reason for converting DAO to ADO is for those applications that use data binding. There
is no migration path for DAO data binding in .NET. However, you can use ADO data binding in .NET.

While I would agree that DAO is a bit more effective with respect to support of Jet than ADOX, in
most instances ADOX is suitable and uses fewer resources than DAO. I haven't found it to be slow and
buggy, but you have to remember that OLEDB adds a layer of access to Jet and that can affect
performance. I certainly wouldn't recommend DAO over ADO simply because it has a small performance
edge.

In any event, I didn't intend to go beyond the scope of the question. But if you check around you
will find very little (if any) support by Microsoft for DAO under .NET, other than the PIA which was
designed more for automation interop issues with Office applications in general. It certainly isn't
a ringing endorsement for the use of DAO over more current data access methods such as ADO, which
Microsoft apparently has determined does not require a custom interop assembly.


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

On Thu, 03 Jul 2003 15:53:21 -0400, Mary Chipman <mchip@nomail.please> wrote:

¤ On Thu, 03 Jul 2003 08:43:01 -0500, Paul Clement
¤ <UseAdddressAtEndofMessage@swspectrum.com> wrote:
¤
¤ >In any event, I didn't intend to go beyond the scope of the question. But if you check around you
¤ >will find very little (if any) support by Microsoft for DAO under .NET, other than the PIA which was
¤ >designed more for automation interop issues with Office applications in general. It certainly isn't
¤ >a ringing endorsement for the use of DAO over more current data access methods such as ADO, which
¤ >Microsoft apparently has determined does not require a custom interop assembly.
¤
¤ The "scope" of the original question was how to create an Access
¤ database in a .NET app. You can't do that using ADO. So the choice
¤ here is between ADOX--incomplete functionality, no PIA, and DAO--PIA,
¤ complete functionality, better performance, less verbose code, fewer
¤ bugs. If you've never hit any of the bugs or incomplete functionality,
¤ then you've not delved deeply into ADOX. Microsoft probably figured it
¤ would be a waste of time to build a PIA for ADO -- you're supposed to
¤ be using ADO.NET for data access, not going to the interop layer. Why
¤ waste resources on a PIA for ADO when the right choice is not to use
¤ it? As far as developing a PIA for ADOX, that would have been another
¤ waste of resources on a technology that was always inadequate. At
¤ least DAO is stable, relatively bug-free, and yes, will continue to be
¤ supported in spite of the naysayers.

I think you're missing the point a bit here. ADO and ADOX don't require a custom PIA as they both
operate quite well under .NET with the runtime generated PIA. ADOX had one bug that I'm aware in the
interop layer, but otherwise I have a fair amount of functional interop code that creates and
modifies Access database files using ADOX. It certainly isn't any more verbose than DAO code.

You also have to remember that not all existing applications can be immediately ported to ADO.NET
and must run under ADO via interop until they can be converted. The migration from ADO to ADO.NET is
the recommended and *supported* path.

Not sure who the "naysayers" you are referring are, but they must be from Microsoft. Officially, DAO
is not undergoing any new development, they're not guaranteeing that DAO will function under .NET,
it isn't thread safe (as ADO is) and they have no plans on fixing any bugs that show up under .NET.

Contrary to what you say, the official word is that it isn't supported:

INFO: Microsoft .NET Framework Does Not Support Data Access Object
http://support.microsoft.com/defaul...b;EN-US;Q311058


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

When you create .net apps with ADO (not Ado.Net) are you running unmanaged?

Byron...

"Paul Clement" <UseAdddressAtEndofMessage@swspectrum.com> wrote in message
news:7sqigvkofs9to5t6uk17usi4gojbpuvh83@4ax.com...
> On Thu, 03 Jul 2003 15:53:21 -0400, Mary Chipman <mchip@nomail.please>
wrote:
>
> ¤ On Thu, 03 Jul 2003 08:43:01 -0500, Paul Clement
> ¤ <UseAdddressAtEndofMessage@swspectrum.com> wrote:
> ¤
> ¤ >In any event, I didn't intend to go beyond the scope of the question.
But if you check around you
> ¤ >will find very little (if any) support by Microsoft for DAO under .NET,
other than the PIA which was
> ¤ >designed more for automation interop issues with Office applications in
general. It certainly isn't
> ¤ >a ringing endorsement for the use of DAO over more current data access
methods such as ADO, which
> ¤ >Microsoft apparently has determined does not require a custom interop
assembly.
> ¤
> ¤ The "scope" of the original question was how to create an Access
> ¤ database in a .NET app. You can't do that using ADO. So the choice
> ¤ here is between ADOX--incomplete functionality, no PIA, and DAO--PIA,
> ¤ complete functionality, better performance, less verbose code, fewer
> ¤ bugs. If you've never hit any of the bugs or incomplete functionality,
> ¤ then you've not delved deeply into ADOX. Microsoft probably figured it
> ¤ would be a waste of time to build a PIA for ADO -- you're supposed to
> ¤ be using ADO.NET for data access, not going to the interop layer. Why
> ¤ waste resources on a PIA for ADO when the right choice is not to use
> ¤ it? As far as developing a PIA for ADOX, that would have been another
> ¤ waste of resources on a technology that was always inadequate. At
> ¤ least DAO is stable, relatively bug-free, and yes, will continue to be
> ¤ supported in spite of the naysayers.
>
> I think you're missing the point a bit here. ADO and ADOX don't require a
custom PIA as they both
> operate quite well under .NET with the runtime generated PIA. ADOX had one
bug that I'm aware in the
> interop layer, but otherwise I have a fair amount of functional interop
code that creates and
> modifies Access database files using ADOX. It certainly isn't any more
verbose than DAO code.
>
> You also have to remember that not all existing applications can be
immediately ported to ADO.NET
> and must run under ADO via interop until they can be converted. The
migration from ADO to ADO.NET is
> the recommended and *supported* path.
>
> Not sure who the "naysayers" you are referring are, but they must be from
Microsoft. Officially, DAO
> is not undergoing any new development, they're not guaranteeing that DAO
will function under .NET,
> it isn't thread safe (as ADO is) and they have no plans on fixing any bugs
that show up under .NET.
>
> Contrary to what you say, the official word is that it isn't supported:
>
> INFO: Microsoft .NET Framework Does Not Support Data Access Object
> http://support.microsoft.com/defaul...b;EN-US;Q311058
>
>
> Paul ~~~ pclement@ameritech.net
> Microsoft MVP (Visual Basic)

On Wed, 9 Jul 2003 08:33:31 -0700, "Byron Hopp"
<bhopp@matrixcomputer.com> wrote:

>When you create .net apps with ADO (not Ado.Net) are you running unmanaged?

Yes.

-- Mary
MCW Technologies
http://www.mcwtech.com

On Wed, 09 Jul 2003 20:39:23 -0400, Mary Chipman <mchip@nomail.please> wrote:

¤ >Contrary to what you say, the official word is that it isn't supported:
¤ >
¤ >INFO: Microsoft .NET Framework Does Not Support Data Access Object
¤ >http://support.microsoft.com/defaul...b;EN-US;Q311058
¤
¤ This article is just plain wrong. It was written before the Office
¤ PIAs were released. I've brought it to the attention of the Access
¤ team, which has taken over Jet enhancements and by extension DAO, and
¤ they are either going to remove or rewrite it to clarify the extent to
¤ which DAO is supported in .NET. Using the DAO PIA is a much better
¤ choice than interop with ADOX, which doesn't have a PIA.

We're just doing to have to agree to disagree which is better to use. I can't recommend DAO under
..NET because of it's bloated and dated object model, threading issues, and poor migration path to
ADO.NET.

With respect to support, until the KB article is changed and PSS has been notified - DAO isn't
supported. At least one if not more PSS folks here has echoed the same statement before. BTW, the
article was recently updated for the 1.1 framework.

I don't know what Jet enhancements the Access team is referring to because Microsoft has already
indicated that the technology has been deprecated.

http://msdn.microsoft.com/library/d..._deprecated.asp

¤
¤ Ask yourself this: Why would msft go to all the trouble of releasing a
¤ PIA for DAO if they didn't intend to support it and for people to use
¤ it?

I think you're begging the question. DAO is still in use and I'm sure there are existing
applications that will be ported to VB.NET and will need to run *as is* for a certain period of
time. It's a stop-gap measure for DAO. The PIA was primarily developed for overall Office automation
issues .


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

On Wed, 9 Jul 2003 08:33:31 -0700, "Byron Hopp" <bhopp@matrixcomputer.com> wrote:

¤ When you create .net apps with ADO (not Ado.Net) are you running unmanaged?
¤

You're .NET code is still managed but ADO code execution is unmanaged.


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

On Thu, 10 Jul 2003 08:46:42 -0500, Paul Clement
<UseAdddressAtEndofMessage@swspectrum.com> wrote:

>With respect to support, until the KB article is changed and PSS has been notified - DAO isn't
>supported. At least one if not more PSS folks here has echoed the same statement before. BTW, the
>article was recently updated for the 1.1 framework.

What can I say -- I've been in direct contact with the Access team,
and it ***IS SUPPORTED***. Perhaps not by .NET folks, but definitely
by the Office team. They are working on updating the article, which is
incorrect and outdated. They are working on clarifying when it is
appropriate to use DAO in .NET (it obviously isn't recommended for
data binding).

>I don't know what Jet enhancements the Access team is referring to because Microsoft has already
>indicated that the technology has been deprecated.

New features have been added in Office 2003 for sandboxing the Jet
expression service and for linking tables to Sharepoint lists. Perhaps
in the past msft "indicated" that the technology has been deprecated,
but that is outdated information. At one time there was a political
movement inside of msft to kill Jet, but it failed. Jet ain't dead,
and has been revised and updated for Office 2003 and will continue to
be updated as needed into the future. These new features and the plans
for the future were publicly announced at the Advisor Devcon in Las
Vegas in June at the keynote address and in serveral sessions. You can
get the skinny on new Access/Jet features yourself on the Office2003
beta ng's and msdn.

You can keep saying it's deprecated all you want, but you are doing
the lurkers on the newsgroups a disservice, which is the only reason I
keep coming back on this thread. Constant repetition of a falsehood or
error does not make it true.

-- Mary
MCW Technologies
http://www.mcwtech.com