Re: Am I wrong

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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 butt..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



Relevant Pages

  • Re: Access 2007 bug with SQL Server Back End
    ... The form was not updatable at all until I set the UniqueTable property. ... I could then perform updates. ... apparently ADO has a long reach. ... That bypasses my triggers, so won't work for this application. ...
    (comp.databases.ms-access)
  • Re: Access 2007 bug with SQL Server Back End
    ... I typically don't work with triggers but have seen other report problems with using triggers, especially INSTEAD OF ones, which could interfere with Access' operations. ... Basically, if you have a source that joins more than one table and that causes the query to be non-updatable because we can't uniquely identify all components back to their originating source, but if we only need to edit one table, we can set the UniqueTable property (which is actually a shortcut into ADO recordset's property of a similar name) that instructs Access/ADO that only one table needs to be updatable and the rest are just for display. ... I was not clear whether your view allow updates to both tables and if that is the case, then I am inclined to think we need to look at the ResyncCommand which is where we basically change how Access/ADO updates the local cache after it issues an update to the source. ...
    (comp.databases.ms-access)
  • Re: Recordset.AddNew and the recordset objects data retaining
    ... via an ADO recordset, then I'd strongly suggest you redesign your solution. ... > to do with the updates being in a transaction but rather on whether you specify ... > spill over and the memory starts paging out to disk that concerns me). ...
    (microsoft.public.data.ado)
  • RE: SP to ADO interaction
    ... > I am a newbie to ADO and mystified by this: ... > that updates 4 different tables sequentially. ... > Dim oCmd As ADODB.Command ... > Set cnn = New ADODB.Connection ...
    (microsoft.public.sqlserver.programming)
  • Re: VS 2003.net
    ... retry some connections and then try the create function again. ... myRS is an ado recordset connecting to an ODBC database and a single table. ... IsDBNull does not return the correct value causing runtime errors. ...
    (microsoft.public.dotnet.languages.vb)