[quoted text, click to view] "Manuel" <My@NoMailLand.com> wrote in message
news:kYCdndYpE6qQdh7cRVn-ug@giganews.com...
> 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!
DataSets solve this problem.
[quoted text, click to view] > 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.
>
Hmm. Transactions work fine.
[quoted text, click to view] > 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.
>
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