Re: ADO.net Code contest

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 ... These provider are widely available. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: RecordSet fails if a field is null ! - unspecified error 80004005
    ... Yeah thats what I was doing to be sure. ... Could your database be corrupt? ... Maybe something is wrong with your Jet components. ... I didnt think you could use ODBC with access... ...
    (microsoft.public.scripting.vbscript)
  • Re: Standard DBI Proposal
    ... I find the lack of an ODBC driver on non-Windows ... an SQL layer over just such an ODBC ... If you're asserting that Tcl entirely lacks an interface to ODBC ... we will be living with multiple database ...
    (comp.lang.tcl)
  • Re: MCP and SQL
    ... provides an ODBC driver interface. ... DMSQL provides the SQL CLI interface, which is also very similar to the ODBC ... but only interfaces to a local DMSII or SQL database. ...
    (comp.sys.unisys)
  • Re: Replacement for Dao
    ... then open both and fetch from the database. ... Jet Engine to be deprecated soon - in fact Jet will not be available at all ... > that Jet actually provides ADO support through its ODBC (I am still ... > was straight forward in Dao) and hence ODBC may perform better than ADO. ...
    (microsoft.public.vc.database)