OleDb, Odbc, Sql classes

  • Thread starter Thread starter news.microsoft.com
  • Start date Start date
N

news.microsoft.com

Why didnt we just have one class that made the db underneath just coded in
one way, now we got 3 diff ways.

Couldnt it have just been one? Doint they all do the same thing except
differently under the hood.

Why should I have to choose when I only want to do ONE thing, access a
database.
 
news.microsoft.com said:
Why didnt we just have one class that made the db underneath just coded in
one way, now we got 3 diff ways.
Click to expand...

Well, 2 really: OLEDB and SQLClient. ODBC is available from within the
OLEDB namespace.
Couldnt it have just been one? Doint they all do the same thing except
differently under the hood.
Click to expand...

The classes in the SQLClient namespace are tuned specifically for SQL
Server. If you are not going against SQL Server, use the classes in the
OLEDB namespace. Seems pretty easy to me.
Why should I have to choose when I only want to do ONE thing, access a
database.
Click to expand...

You said it yourself, each DB product works differently under the hood.
 
Yeah its easy duh, but couldnt they just do all that selection and tuning
crap under the hood and just expose one API.
 
news.microsoft.com said:
Why didnt we just have one class that made the db underneath just coded in
one way, now we got 3 diff ways.
Click to expand...

Tuning of the data retrieval would be a good guessing, I think.
Couldnt it have just been one? Doint they all do the same thing except
differently under the hood.
Click to expand...

You do not have to code explicit for each of the data classes.
Technically they all implements the same interfaces like IDbConnection
and so on. So if you code by using interfaces instead of using OleDb,
Odbc and Sql classes directly, your code will be completely transparent
to whatever type of connection used. One coding technique for all.
Why should I have to choose when I only want to do ONE thing, access a
database.
Click to expand...

Do "one thing" with the coding technique and choose any of the type of
connections as an input for creating a connection instance, by using
interfaces instead of classes.
 
In a way, there is only one API. At some point you have to tell it whether
you are going against SQL or not. So you do that by using either the OLEDB
namespace or the SQLClient namespace.

After that, you use the classes just the same, for example a
SQLClientDataAdapter and an OLEDBDatatAdapter expose the SAME API, you've
just got to choose the right one for the right DB.

Doesn't seem that complicated to me.
 
Yeah its easy duh, but couldnt they just do all that selection and
tuning crap under the hood and just expose one API.
Click to expand...

Well then it wouldn't be tuned now would it. If you just want to not have
to change your code, and don't want to be stuck using the slower ODBC or
OLEDB engines then using generic database coding practices.

Generic database coding library here:

http://sourceforge.net/projects/genadonet

I have a powerepoint you can download on it here:

http://prdownloads.sourceforge.net/genadonet/Writing_DB_ind_code.zip?
download

Michael Lang, MCSD
 
Back
Top