Re: Am I wrong

From: William \(Bill\) Vaughn (billvaRemoveThis_at_nwlink.com)
Date: 02/09/04 

Date: Sun, 8 Feb 2004 18:43:18 -0800

If you go over to the ADO classic newsgroups you'll see countless questions
and complaints about deployment and problems with programs working on one
platform or not another. You'll also find programs that work when first
deployed, but stop working later for unexplainable reasons. This it the
nature of COM. We lobbied Microsoft for years to fix it. They did. ADO.NET
is build without the need for COM. While it requires MDAC for its netlibs,
ADO.NET is not affected by MDAC "upgrades".

ADO classic (what I dub ADOc) Update method black box makes a number of
arbitrary decisions about concurrency and while it gives you more
flexibility today (you can change the Update behavior by using the Update
Criteria property), I expect the Whidbey version of ADO.NET to be more
flexible in this respect. However, consider that serious applications have
trouble using ADOc Update--even when carefully tuned. That's because the
Update method makes a fundamentally flawed assumption--that you're directly
updating a database table. In most scalable professional systems, we've seen
that data tables are neither queried nor updated directly. In these systems
stored procedures form the first line of interface to the data--it's a
common and widely used practice. While it's harder to implement this
approach, it's safer, faster and far more scalable. None of these developers
complain about the memory footprint of a Dataset (or a Recordset) because
it's so small. That's because they fetch very few rows from the stored
procedures and rarely all the rows of a table. Sure, lookup tables are
queried as a whole, but in this case the number of rows is typically a few
hundred or fewer rows and rarely updated from a typical client application.

ADO.NET is part of the .NET Framework and it's very different than ADOc. It
approaches data access problems with entirely new technology. For the first
time the data provider can use the low-level "native" protocol without
having to go through an one-size-fits-all OLE DB providers. This means
ADO.NET can be faster, lighter and expose more of the target DBMS features
than ADOc.

Sure, these differences make ADO.NET harder to learn. I've found that if you
don't try to compare the two, you're better off. There are so many
differences that it's just easier to think of ADO.NET as a whole new game.
I discuss the transition between ADOc and ADO.NET in my books.

hth 

-- 
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"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
>
>