Re: ADO.net Code contest

Bill,

Please see the reply to Sahil for the reason of going through this
excercise. I agree, this is not a typical use of Access.

Thanks for your comments.

Brian

"William (Bill) Vaughn" wrote:

> Ah, actually, accessing an Access database is done through JET. If you use a
> generic interface like OLE DB or ODBC from any data access interface (DAI)
> you get...
>
> DAI -> System.Data.OleDb -> JET .NET provider -> JET API
> or
> DAI -> System.Data.Odbc-> JET ODBC driver-> JET API
> or
> DAI -> ODBC API-> JET ODBC driver-> JET API
> or
> DAI -> OLE DB COM interface-> JET OLE DB provider-> JET API
> unless you use DAO
> DAO->JET API
>
> Trying to get more performance out of JET by choosing one provider is an
> interesting approach, but hardly useful. ODBC, OLE DB are
> "one-size-fits-all" (OSFA) interfaces designed to permit a (mostly) common
> DAI to be able to access a variety of backend data sources like JET, SQL
> Server, Oracle, DB2 and the rest. To access a data source with the least
> overhead, you need to use the "native language" interface--not a generic
> intermediate layer. Most DBMSs has their own unique native language. For JET
> the only public interface is DAO as its API interface is not published
> outside of Microsoft. For SQL Server the public interface is DB-Library (the
> TDS protocol is proprietary).
>
> However, arguing which is faster is academic. It's not how fast you ask the
> question, its how fast the question can be answered that determines true
> database performance. DAO, RDO, ADO, ADO.NET and the OSFA interfaces were
> not designed for bulk operations as your test suggests. They are query
> interfaces and they all wait at the same speed. For SQL Server (and other
> business-class DBMSs), there are special utilities (BCP/DTS etc.) that are
> specifically designed do this work. JET has no such utility--but Access
> does. Access knows how to use JET APIs and locking schemes to import data
> faster than any DAO-driven program can. There are also JET Replication
> Object (JRO) COM APIs that developers can use to manipulate JET databases.
>
> Again, the ability to flood a database with data is not a typical
> application task--especially not with a database engine like JET. The
> various data access interfaces listed above were designed to make
> programming easier, to make development of code generators easier, to make
> it possible to access data without having to know how to use the complicated
> ODBC API and the mind-boggling OLE DB COM++ interface. ADO.NET has done
> something different for most backend data sources--it has exposed new
> "managed" .NET Data Providers that speak the native tongue of specific
> backends. These provider are widely available. The Framework ships with SQL
> Server and Oracle managed providers as well as an Odbc .NET Provider. It
> also includes an OleDb .NET Provider that's suitable only for cases where a
> "native" managed provider is not available. This is the case for JET and one
> reason why it takes longer to get data to and from JET via ADO.NET.
>
> And folks, even a Ferrari won't beat a bicycle in heavy traffic. Anyone who
> has witnesses traffic in Bangkok can tell you that.
>
> hth
>
> --
> ____________________________________
> William (Bill) Vaughn
> Author, Mentor, Consultant
> Microsoft MVP
> INETA Speaker
> www.betav.com/blog/billva
> www.betav.com
> Please reply only to the newsgroup so that others can benefit.
> This posting is provided "AS IS" with no warranties, and confers no rights.
> __________________________________
>
> "Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xxxxxxxxx> wrote in message
> news:xn0eh3unbabflr000@xxxxxxxxxxxxxxxxxxxxx
> > Cor Ligthert [MVP] wrote:
> >
> >> > Jesús López wrote:
> >> >
> >> >> May I use DAO 3.6 instead of ADO.NET or ADODB ?
> >> > >
> >> >> I think DAO is the fastest way to deal with Access databases.
> >> > >
> >> >> Regards from Madrid (Spain)
> >> >> Jesús López
> >> >
> >> > No, ODBC is (if I recall correctly). That is, raw C++ with odbc.
> >> >
> >> If you use a Ferrari maybe, however with a bicycle it is much slower.
> >>
> >> What has ODBC to do with comparing DAO, ADO or ADONET?
> >
> > erm... you can use odbc instead of oledb in ado.net? Accessing access
> > is done through oledb, so picking odbc is the same.
> >
> > FB
> >
> > --
> > ------------------------------------------------------------------------
> > Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
> > My .NET blog: http://weblogs.asp.net/fbouma
> > Microsoft MVP (C#)
> > ------------------------------------------------------------------------
>
>
>
.

Relevant Pages

  • Re: ADO.net Code contest
    ... Ah, actually, accessing an Access database is done through JET. ... generic interface like OLE DB or ODBC from any data access interface ... ODBC, OLE DB are ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: How to determine if an ADO Recordset column is required
    ... > OLEDB (Jet), I was finally able to locate a Properties that is almost ... I do not understand your obsession about using the obsolete ODBC provider. ... your application has to go through two software layers: the OLE DB ...
    (microsoft.public.inetserver.asp.db)
  • Re: Data Connections into dBase files
    ... What you could do is to use Jet 4.0 provider or ODBC provider. ... > How can I make connections into this/that folder/files in VB.NET project? ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Access SQL Scalar Function DAYOFWEEK Problem
    ... by the JET ODBC driver for the JET engine to understand and process the ODBC ... Scalar Function DAYOFWEEK. ... Dim strConn As String ...
    (microsoft.public.access.queries)
  • Re: [Access2003, VBA] Use DAO or ADO?
    ... One of the reasons my clients preferred Access / Jet / ODBC was that they ... Autonumber or its server equivalent and could have been shown to the users ... real world of development, Dot Net", ADO has been superceded by ADO.NET ...
    (comp.databases.ms-access)
Loading