OleDB vs SQL

  • Thread starter Thread starter Brad Allison
  • Start date Start date
Assuming you mean the SQLClient library vs. the OleDB library:

In general, this is going the be the case with most providers, you'll get
more speed out of a native provider. Also, there is functionality
associated with many custom providers that may not be associated with a more
generic provider. I was at a usergroup meeting and the analogy the guy made
was with clothing....an off the rack suit may work fine for your needs, but
a tailor made suit is going to fit better. I've also heard that as the
framework matures, the more the profound the distinctions will be.

HTH,

bill
 
Mr. Ryan is on the right track here. The OleDb provider is designed as a
"one-size-fits-all" interface designed to permit a bevy of OLE DB provider
to expose their specific data sources. It's one big drawback is that it's
not .NET managed code so it is subject to some of the DLL hell issues we've
all been encountering over the years. Because it requires use of the COM
interop layer, it's also slower and less feature-rich than native providers.

When choosing a provider, pick the native provider first (if there is one),
Odbc next (its managed code and faster), and the OleDb provider last--but
only after having gone back and making doubly sure there is no native
provider.

hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
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.
__________________________________
 
Hi Bill,
When choosing a provider, pick the native provider first (if there is one),
Odbc next (its managed code and faster), and the OleDb provider last--but
only after having gone back and making doubly sure there is no native
provider.
Click to expand...
Almost every example on MSDN is with OLEDB, do you think Microsoft does that
to bring customers in the wrong direction?

ODBC is almost out in NET and only partionaly usable as far as I know.

As far as I know is in Net 1.1 Oledb full implementated

Or did you make a mistake?

Cor
 
I think they do that because it's more convenient. When I wrote docs for
Microsoft, they asked us to write "generic" examples that did not favor one
vendor (SQL Sever over Oracle over JET over DB2) over another. Yes, I think
this is another reason to read my books that try hard to always use "best
practices" when showing examples. While I'm not the only author that does
this, I'm disappointed in the number of examples that remain that show poor
programming practices...
ODBC is certainly older than OLE DB, but it's now built into the Framework
and being managed code it's faster and safer.

hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
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.
__________________________________
 
Hi Bill,

I see you have good contacts with Microsoft, mayby you can ask them to
remove this part of the documentation on MSDN.
.............
The System.Data.OleDb namespace is the .NET Framework Data Provider for OLE
DB.

The .NET Framework Data Provider for OLE DB describes a collection of
classes used to access an OLE DB data source in the managed space. Using the
OleDbDataAdapter, you can fill a memory-resident DataSet, which you can use
to query and update the data source.

Or do I understand your words I pasted in beneath wrong again?
.............
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemdataoledb.asp

providers.
Click to expand...

Cor
 
You misunderstood. OleDb can do everything it says in the doc you
referenced. However, it's not the best choice and should not be your first
choice. Yes, I think they (Microsoft) should add "this provider is to be
used when there are no other native providers available and only with a note
from your mom".

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
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.
__________________________________
 
Hi Bill,

So I understand this statement of you stays "Because it requires use of the
COM
interop layer, it's also slower and less feature-rich than native providers"

Cor
 
Precisely. Since the native providers can (and do) take advantage of the
features of the target DBMS, and they don't have to worry about
cross-compatibility problems, they can be lighter and faster while
supporting more functionality.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
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.
__________________________________
 
I don't see anything in this document that contradicts what I said.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
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.
__________________________________
 
Back
Top