Groups | Blog | Home
all groups > dotnet ado.net > october 2004 >

dotnet ado.net : Advantages of the ADO.NET connection?


David Browne
10/30/2004 3:05:40 PM

[quoted text, click to view]

DataSets solve this problem.

[quoted text, click to view]
Hmm. Transactions work fine.

[quoted text, click to view]

If you stick to DataReaders you will never love ADP.NET. ADO.NET stomps old
ADO with DataSets, especially Strong-Typed DataSets. Imo this is _the_
reason to use ADO.NET. You can easilly navigate related table and bind your
application code to your database metadata, etc.

They really make your application more robust, more type-safe, easier to
code, fix, maintain etc.

EG this bit of ADO


do while not rsCustomers.eof
rsOrders.find("name= '" & rs("name") & "')
do while not rsOrders.eof
orderTotal = orderTotal + rsOrders("amt")
rsOrders.MoveNext
loop
rsCustomers.MoveNext
loop

becomes

for each customer as CustomerRow in oe.CustomerTable.Rows
for each order as OrderRow in customer.Orders
orderTotal += order.amt
next
next


David


Manuel
10/30/2004 3:27:25 PM
I've read all over the web how hot and sexy ADO.NET is, but when it's coding
time I just don't see the benefit (at least for me as a programmer).

The biggest complains I have are:

1) I cannot open 2 simultaneous streamreaders with a single connection. When
I stumbled upon this I couldn't believe it!
2) The transactions sound good on paper but terrible when implementing. I
wanted to do something as simple as open a connection, open a transaction
and do all sorts of twists and turns to the data using the same transaction.
I couldn't! Part of this was because of the first reason.

After trying to use it on a real world application, I decided to go back to
the old ADO.

What am I missing? So far the only place where I've seen ADO.NET shine is
populating a databound control. But when it comes to programmatically handle
the data, it's more of a hassle compared to the old ADO.

Miha Markic [MVP C#]
10/30/2004 9:57:05 PM

[quoted text, click to view]

This is a limitation which I wouldn't say it is critical.

[quoted text, click to view]

Why don't you read data first, do the modifications and then store modified
data? What were the other problems?

[quoted text, click to view]

What a mistake.

[quoted text, click to view]

Don't get me wrong, but I really don't want to make an essay on ado.net. If
you read help file + various articles and you still don't get it - what can
I say - you are missing a lot.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
miha at rthand com
www.rthand.com

CT
10/31/2004 9:32:05 AM
Manuel,

I think you might want to give ADO.NET another chance. I second what Miha
and David writes, but in addition, I can add how much trouble I had when
moving from classic ADO to ADO.NET some years back. I think the main
obstacle is to think disconnected, which is what I believe your problems
start. Give it another; I'm sure you won't regret it. That's not to say that
classic ADO can't be used anymore, because it can. Things like ADOX still
works very well with Jet databases, for instance.

--
Carsten Thomsen
Enterprise Development with VS .NET, UML, and MSF
http://www.apress.com/book/bookDisplay.html?bID=105
[quoted text, click to view]

Sahil Malik
10/31/2004 10:30:29 PM
Manuel,

I worked on a project involving 650 disconnected servers and 3000+
disconnected clients across the united states. Try doing that in ADO
classic.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik



[quoted text, click to view]

AddThis Social Bookmark Button