Don't use ADO.Net !

Hi,

I was just investigating into ADO.Net when I suddenly realized what
Microsoft had done !

As long as you are only dealing with one database type and that you
are sure that you will keep it for the rest of your application life
everything is ok !

Now what about having one odbc database, one oledb database, one
Oracle db and one sql server one !?

In the past ... ADO accepted connection string and that is all ! You
could do everything just with an ADO connection ! If ADO choose to
create an OracleConnection, a SQLConnection or whatever else, I did
not have to know !

Tha same with ADOX ! This was a generic way to retrieve meta infos
from a database ... that too is completely messed up in ADO.Net !

I really would like to know who was responsible for this part of
ADO.Net and I would really be able to have a word with him !

What do we have to do now ?

Just implement multiple database support ourself, and reference "old"
stuff like ADOX and the Datalinks object ...

With ADO.Net we are just about to make a huge jump 5 years in the past
....

Dotnet is like Java ... well yes ... but Java 5 years ago !

Bye !

Microsoft provides optimized data adapters for improved performance, such as
SQL Server adapters in the System.Data.SqlClient namespace. They also
provide an oledb adapter (System.Data.OleDb), and an ODBC adapter (separate
download, in a namespace System.Data.Odbc) for data access to a multitude of
data stores including those you mentioned. The Factory pattern can be used
to enable your application to optimize the choice of a suitable adapter.

--
James J. Foster, DotNetCoders
http://www.dotnetcoders.com


"arkam" <arkam@caramail.com> wrote in message
news:e185dcd1.0306300346.470769a5@posting.google.com...
> Hi,
>
> I was just investigating into ADO.Net when I suddenly realized what
> Microsoft had done !
>
> As long as you are only dealing with one database type and that you
> are sure that you will keep it for the rest of your application life
> everything is ok !
>
> Now what about having one odbc database, one oledb database, one
> Oracle db and one sql server one !?
>
> In the past ... ADO accepted connection string and that is all ! You
> could do everything just with an ADO connection ! If ADO choose to
> create an OracleConnection, a SQLConnection or whatever else, I did
> not have to know !
>
> Tha same with ADOX ! This was a generic way to retrieve meta infos
> from a database ... that too is completely messed up in ADO.Net !
>
> I really would like to know who was responsible for this part of
> ADO.Net and I would really be able to have a word with him !
>
> What do we have to do now ?
>
> Just implement multiple database support ourself, and reference "old"
> stuff like ADOX and the Datalinks object ...
>
> With ADO.Net we are just about to make a huge jump 5 years in the past
> ...
>
> Dotnet is like Java ... well yes ... but Java 5 years ago !
>
> Bye !

Arkam,



> Now what about having one odbc database, one oledb database, one
> Oracle db and one sql server one !?



I think this comment shows where you are seeing the problem, there is no
Odbc or Oledb database. Both Odbc and Oledb are general api's used to
connect to multiple databases. It works something like this:



I am a database vendor, I make database X. I want people to use database X
so I release an Oledb native provider so that developers can talk to my
database.



I am a database developer and I am using the Oledb api to connect to
database Y via the Y Oledb native provider, I want to move all of my code to
use Database X. I see that database X has an Oledb native provider, I link
it to my project and change the connection string. I am done.



If the functionally you are looking for is multiple database support then
you can use the Oledb or Odbc managed providers. Both of them work for all
databases that you have a native Oledb or Odbc provider for. Right here you
have all of the functionality that you seem to be missing from ADO.



So why do we need the SqlClient and Oracle specific providers? Well, when
you make an api to work with all types of databases you are going to give up
performance and miss support for some very interesting database specific
functionality. By releasing a SqlClient and Oracle specific managed
providers we were able to support functionality like SqlTypes, ref cursors,
blobs, and visual studio specific support. All of this while making access
much much faster than it was possible to do with the generic model. This is
a big win for developers that know they are going to be using a specific
database.



I really like the current design and allthough a minor player in the design
definitelly backed it from day one. It is a good thing to be able to talk to
all databases, it is a better thing to be able to talk to all databases if
you want, or to get the database specific features and performance if you
want.

Hope this helped,
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.



"arkam" <arkam@caramail.com> wrote in message
news:e185dcd1.0306300346.470769a5@posting.google.com...
> Hi,
>
> I was just investigating into ADO.Net when I suddenly realized what
> Microsoft had done !
>
> As long as you are only dealing with one database type and that you
> are sure that you will keep it for the rest of your application life
> everything is ok !
>
> Now what about having one odbc database, one oledb database, one
> Oracle db and one sql server one !?
>
> In the past ... ADO accepted connection string and that is all ! You
> could do everything just with an ADO connection ! If ADO choose to
> create an OracleConnection, a SQLConnection or whatever else, I did
> not have to know !
>
> Tha same with ADOX ! This was a generic way to retrieve meta infos
> from a database ... that too is completely messed up in ADO.Net !
>
> I really would like to know who was responsible for this part of
> ADO.Net and I would really be able to have a word with him !
>
> What do we have to do now ?
>
> Just implement multiple database support ourself, and reference "old"
> stuff like ADOX and the Datalinks object ...
>
> With ADO.Net we are just about to make a huge jump 5 years in the past
> ...
>
> Dotnet is like Java ... well yes ... but Java 5 years ago !
>
> Bye !

You can access all these db types with one and the same interface, the
OLeDBConnection:
*.txt, *.csv, *.xls, *.dbc, *.dbf, and more, even MS sql server; only the
connection strings differ.
You would setup these connection strings once in your .net life. But having
saved all this work, you would speed up access to MS SQL server by using the
SQLconnection.



"arkam" <arkam@caramail.com> wrote in message
news:e185dcd1.0306300346.470769a5@posting.google.com...
> Hi,
>
> I was just investigating into ADO.Net when I suddenly realized what
> Microsoft had done !
>
> As long as you are only dealing with one database type and that you
> are sure that you will keep it for the rest of your application life
> everything is ok !
>
> Now what about having one odbc database, one oledb database, one
> Oracle db and one sql server one !?
>
> In the past ... ADO accepted connection string and that is all ! You
> could do everything just with an ADO connection ! If ADO choose to
> create an OracleConnection, a SQLConnection or whatever else, I did
> not have to know !
>
> Tha same with ADOX ! This was a generic way to retrieve meta infos
> from a database ... that too is completely messed up in ADO.Net !
>
> I really would like to know who was responsible for this part of
> ADO.Net and I would really be able to have a word with him !
>
> What do we have to do now ?
>
> Just implement multiple database support ourself, and reference "old"
> stuff like ADOX and the Datalinks object ...
>
> With ADO.Net we are just about to make a huge jump 5 years in the past
> ...
>
> Dotnet is like Java ... well yes ... but Java 5 years ago !
>
> Bye !

Hi,

Ok, I see that neither James nor Angel have really understood my
problem.

I have nothing again multiple providers optimized for one particuliar
database.
Those who have to work with only one database type will enjoy this !
That is a good point !

The problem is that the ease which could be found in ADO cannot be
found in ADO.NET and that is the bad point.

That means :

-More time spent by developpers all around the world writting the same
"Factory" code.
-More time spent by developpers all around the world trying tips &
tricks to get the same level of features than in ADO.
-Not the same functionality with the beta odbc driver than in ADO
-Not a clear class hierarchy for System.Data
-No proper ADOX at all

I see ADO.NET like a way to try to force people to use MS SQL Server.
And, again, this is going to fail and they will have to refactor
ADO.NET in some years to properly include ODBC, UDL and so on ... and
we will have to rewrite our applications in order to support this new
ADO.NET.

It is really stupid ! What I am doing now ?
- link to the DataLink object in the old COM world
- link to ADOX in the old COM world

As long as people have to bind their apps to the old COM world that
will mean ADO.NET is not mature !

Then please don't promote this thing (especially the Oracle or SQL
Clients)... if you don't have to !

Arkam

arkam@caramail.com (arkam) wrote in
news:e185dcd1.0306302252.25987c7b@posting.google.com:
> The problem is that the ease which could be found in ADO cannot be
> found in ADO.NET and that is the bad point.
>
> That means :
>
> -More time spent by developpers all around the world writting the same
> "Factory" code.
> -More time spent by developpers all around the world trying tips &
> tricks to get the same level of features than in ADO.
> -Not the same functionality with the beta odbc driver than in ADO
> -Not a clear class hierarchy for System.Data
> -No proper ADOX at all

Especially the class hierarchy statement is so true. MS messed up
badly when designing data-related namespaces and classes. There is NO WAY
people can write database-generic code, because you can't use interfaces
(because some components like the SqlParameter implement 2 distinct
interfaces) and you can't use base classes (because there ARE no base
classes!). Big mistake.

> I see ADO.NET like a way to try to force people to use MS SQL Server.

More and more I get the feeling it's not about sqlserver, but about
datasets. If you do not want to use datasets or a solution based on
datasets, you're doomed to write a lot of code and you're sure you will
face a lot of misery when doing databinding. Datasets can be a PITA when
you want to work on the entity level, with objects. You can't use datasets
then, because a dataset is a container for more than 1 row, not a single
row and you can't create a single datarow object without a dataset either.

Again, BIG MISTAKE. In .NET it should be about generic code, not
about 1 particular way of doing things and if you do not want that then
you are out of luck. The same mistakes plagued VB for years until ADO was
mature enough but even then you couldn't use a lot of VB functionality
unless you were willing to use the 'data-adapter' (which was stupid in an
n-tier app)

> And, again, this is going to fail and they will have to refactor
> ADO.NET in some years to properly include ODBC, UDL and so on ... and
> we will have to rewrite our applications in order to support this new
> ADO.NET.

I more and more have the feeling we indeed have to yes.

> It is really stupid ! What I am doing now ?
> - link to the DataLink object in the old COM world
> - link to ADOX in the old COM world

ADOX is not that necessary for a lot of applications btw.

FB

--
Solutions Design : http://www.sd.nl
My open source .NET Software : http://www.sd.nl/software
My .NET Blog : http://weblogs.asp.net/FBouma
-------------------------------------------------------------------------

>I have nothing again multiple providers optimized for one particuliar
>database.Those who have to work with only one database type will enjoy this !

Have a look at the Borland Data Providers which are part of their
C#Builder product - they provide a single native ADO.NET provider,
which can basically talk to any important database (Interbase, MS SQL,
Oracle, IBM DB2).

http://www.borland.com/csharpbuilder/

Have a look at the "Data Sheet" and "Tech Overview" PDF's

Marc

================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch

what the **** are you wining about ??? If you don't like ADO.NET, write
your own damn dataset, not that hard !!!





"arkam" <arkam@caramail.com> wrote in message
news:e185dcd1.0306302252.25987c7b@posting.google.com...
> Hi,
>
> Ok, I see that neither James nor Angel have really understood my
> problem.
>
> I have nothing again multiple providers optimized for one particuliar
> database.
> Those who have to work with only one database type will enjoy this !
> That is a good point !
>
> The problem is that the ease which could be found in ADO cannot be
> found in ADO.NET and that is the bad point.
>
> That means :
>
> -More time spent by developpers all around the world writting the same
> "Factory" code.
> -More time spent by developpers all around the world trying tips &
> tricks to get the same level of features than in ADO.
> -Not the same functionality with the beta odbc driver than in ADO
> -Not a clear class hierarchy for System.Data
> -No proper ADOX at all
>
> I see ADO.NET like a way to try to force people to use MS SQL Server.
> And, again, this is going to fail and they will have to refactor
> ADO.NET in some years to properly include ODBC, UDL and so on ... and
> we will have to rewrite our applications in order to support this new
> ADO.NET.
>
> It is really stupid ! What I am doing now ?
> - link to the DataLink object in the old COM world
> - link to ADOX in the old COM world
>
> As long as people have to bind their apps to the old COM world that
> will mean ADO.NET is not mature !
>
> Then please don't promote this thing (especially the Oracle or SQL
> Clients)... if you don't have to !
>
> Arkam