Re: Am I wrong

From: William Ryan eMVP (bill_at_NoSp4m.devbuzz.com)
Date: 02/08/04 

Date: Sun, 8 Feb 2004 14:59:27 -0500

"T. Bernstein" <tbone@12move.nl> wrote in message
news:Z8vVb.65818$Os.53539@amsnews02.chello.com...
> Hello,
>
> I have used ADO for years, and I loved it. When I take a look at ADO.NET,
I
> somehow get the feeling I am worse off. I hope you can convince me of the
> opposite.
>
> Yes, I am more in control, but:
> -- I write a lot more code
> -- A simple update of a record has become a lot more difficult (used to
be:
> recordset.update, period !)
> -- There are a lot more components involved (connection, adapter, dataset,
> table).
>
> Three questions:
>
> 1.
> Do you have some arguments, which could take away my idea, that this
ADO.NET
> is not really an improvement?
>
> 2.
> Is updating a batch of records not very dangerous, because all kinds of
> things could have happened to the records, in the time between FILL and
> UPDATE. How do you control such a mess, and how do you tell the user, that
> update #3 of 40 did not work out? Do I have to extend their memories?
>
> 3.
> Do you use bulk-updates, or one-at-a-time updates? What is your advice?
>
> Thanks in advance
> Jan van Toor
>
>
<<I write a lot more code>> That totally depends on what you are doing and
just as one might make the case they write more code up front, I've found I
write less code overall becuase of the overall flexibility that ADO gives
me.

<< A simple update of a record has become a lot more difficult (used to be:
> recordset.update, period !)>> In it's simplest form, an Update can be
accomplished with either DataAdapter.Update (one line) or using
command.ExecuteNonQuery(which can be a few lines including opening and
closing connections. Either way, not too big of an issue, and with the
Advent of ADO.NET 2.0 where batch updates are supported by simply setting
One property, it's hard to see how this is a big deal

<<> -- There are a lot more components involved (connection, adapter,
dataset,
> table).>> So, you don't have to use them at all to get a lot of thigns
done although that's probably not a good idea. How is having more objects
worse than having fewer? You can refine what you need to do tailored to
your needs. You can do a heck of a lot just using connected objects
(Connection, Commands and DataReaders)

<<Do you have some arguments, which could take away my idea, that this
ADO.NET
> is not really an improvement?>>

Yes, there are tons of them. The main one is that you can model your data
much better with the DataSet/DataTable model. You can relate your tables
using DataRelations so you don't need to pull over redundant data. You can
take data from any datasource and move it to myriad other sources with the
exact same logic. That means I can move my data from SQL Server to my PDA
and then to an Oracle DataBase by simply using a different data adapter.
Also, XML support under ADO is a pain in the ***..it's a dream with ADO.NET

Perhaps in your specific case, you don'thave the need for the new power or
flexibilty, but your needs may change and there are certainly many people
who do need it...and it was a nightmare with ADO.

ADO was the ultimate black box and if you needed new functionality, tough.
Compare that with the ability to subclass a DataReader for instance, or use
Data Objects that don't even need to ever talk to a database....

And best of all, you can use ADO with .NET if you have a compelling reason,
but I can't use ADO.NET with VB6 VC++ < .NET...So you can still do wahtever
you used to plus more..it doesn't work the other way around.

2) It can be, but it isn't necessarily so (and there aren't true Batch
Updates until ADO.NET v2.0). You can use RowUpdated and excpetion handling
to handle such errors any of a hundred different ways. That's not a
limitation in any regards of ADO.NET

3) At present, the DataAdapter only supports one at a time updates so you
can't do bulk updates in the sense that most people think of bulk updates.
Since the DA updates everythign one at a time, there really isn't a question
to answer.

HTH,

Bill