Advantages of the ADO.NET connection?

  • Thread starter Thread starter Manuel
  • Start date Start date
M

Manuel

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.
 
Manuel said:
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!
Click to expand...

This is a limitation which I wouldn't say it is critical.
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.
Click to expand...

Why don't you read data first, do the modifications and then store modified
data? What were the other problems?
After trying to use it on a real world application, I decided to go back
to the old ADO.
Click to expand...

What a mistake.
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.
Click to expand...

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.
 
Manuel said:
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!
Click to expand...

DataSets solve this problem.
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.
Click to expand...
Hmm. Transactions work fine.
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.
Click to expand...

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,

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.
 
Back
Top