Is ADO.NET OleDb .NET Data Provider a COM object?

  • Thread starter Thread starter Mark Worsnop
  • Start date Start date
M

Mark Worsnop

I read that it is a COM wrapper, and if that is the case then why not use the
ADO MDAC as that for sure uses the COM object?

Every where I read says do not use the ADO for VB6, and convert. But I do
not want to be stuck only on SQL Server. Even though that is all I use, I
would also like to have it set so that I could use MySql or another DB at
some time.
 
Mark Worsnop said:
I read that it is a COM wrapper, and if that is the case then why not use
the
ADO MDAC as that for sure uses the COM object?

Every where I read says do not use the ADO for VB6, and convert. But I do
Click to expand...


Who said that? You need to make sure that you know ADO and ADO.NET are
completely different things.

ADO+VB6 is a good fit, while in .NET you can still use ADO, but it is a bad
choice. You can use ADO.NET with all sorts of database server, be itSQL
Server, or MySQL...
 
There is 2 different ADO.NET adapters, OleDB and Native SQL. The SQL is a
direct connection to the SQL Server.

The OleDB I think still uses the COM wrapper.

If it actually does, then why not use the ADO COM?
 
Okay, okay... let's add some clarity here.
First let's define some terms. COM means you build code that depends on
external COM components that might be replaced (often arbitrarily) AFTER
your application has been deployed--even before it runs for the first time.
IMHO COM is a big problem in many environments.
OLE DB is a one-size-fits-all (OSFA) set of providers that can access
anything from a relational database to a tuna salad (unless it has dill
pickles). The spec is as complicated as a pork-filled bill sent out of the
House. OLE DB is based on COM (see above). In the past, in order to access
SQL Server we used OLE DB to access ODBC (the Kagera bridge) or SQL Server.
Today, you can/should use the SNAC OLE DB provider to access SQL Server--but
it's still COM.

A telephone is an example of an OSFA provider. However, just because you can
dial (or push buttons), it does not mean you can order pizza from that guy
in Peru that does not speak English. In a similar way, just because you can
connect to MySQL, Paradox, Oracle or FarkleStar databases from an OLE DB or
other OSFA provider does not mean your code can interface with these other
back-ends. Each has its own unique characteristics, features, weaknesses and
strengths. One might support stored procedures, another not. One might
support BLOBs or enough capacity to store images in the database, another
might not. Some are designed for multi-user architectures, others struggle
to support a single user. The differences in administration, performance,
capacity, compatibility and everything else make writing an OSFA application
of your own a living, breathing nightmare. Yes, it's been done but is the
application competitive? It often takes complex multi-tiered architectures
that dereference the actual data access interfaces and implementations.
Possible? Sure--got a PhD in computer science or a dozen year experience?
Got someone who'll pay for this beast?

Accessing ADO via OLEDB (or the OleDb namespace in .NET) is problematic.
Yes, it has to traverse the COM interop layer which does NOT map the entire
functionality you use to access ADO COM objects in VB6. I documented a
half-dozen cases where the COM interop failed to return the same results or
was even accepted in .NET code--the only reason some of these applications
worked was "side-effect" or unintended functionality exposed by the COM
objects created in VB6. In other words, it only worked by accident.

I hope this answers your question.

--
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
____________________________________________________________________________________________
 
So if I want my application to be able to use SQL server or MySql for
example, the only choice I have is using the OleDB, is that correct. I do
know there are differences in the way you talk to the DB regardless of how
you get there.

If I do us the OleDB and that uses the COM wrapper, then I might as well
use the COM that I used in VB6 too or are they different.

As there is no other way to access MySql other than the OleDB am I to assume
that its ok to use this? Is there another choice?

Thanks for all your input!
 
Ah, first, COM is simply the interface, not the objects to which it
connects.

I recommend that you give up on COM-based ADO if you're working with a .NET
language. (period)

Yes, I expect there are MySQL ODBC drivers and there are MySQL .NET native
providers. I found one here
http://dev.mysql.com/downloads/connector/net/5.0.html. There might be
others. I would (always) recommend a .NET native provider over an OLE DB (or
ODBC) provider. As I discuss in my latest book, using ODBC drivers to access
databases is also faster and less trouble-prone than OLE DB as the interface
is (again) managed code.

--
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
____________________________________________________________________________________________
 
But am I understanding correctly, if there is not a NET driver available, and
you use the OleDB then its like using the ADO COM?

I guess I should have looked for Native NET drivers, before I said anything.
I read your book and it said the NET driver only supported MS SQL. Never
thought of looking for drivers, my bad.

I have almost completed making a DLL that I am going to use in my
application that simulates all of the ADOc function calls. That will make
converting the existing VB6 code tons easier. I will use this for about 90%
of the main code and manually rewrite all of those that are too complicated.
 
Ah, cloning ADO classic functionality might be pretty complex as ADO.NET
does not implement the default ADO classic Recordset or its server-side
cursor functionality. I think many developers have chosen to evaluate each
of the data access routines at a somewhat higher level. This permits them to
code classes that do the same thing in ADO.NET without all of the issues
involving "emulating" the Recordset behavior. That is, if a query runs a
query and returns a rowset, you code a Command object, process the
parameters, execute the Command and process the rowset.

--
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
____________________________________________________________________________________________
 
Back
Top