Re: Need some advice on ADO .NET

From: William \(Bill\) Vaughn (billvaRemoveThis_at_nwlink.com)
Date: 07/01/04

  • Next message: William \(Bill\) Vaughn: "Re: Getting rid of stored procedures" 
    Date: Thu, 1 Jul 2004 13:56:32 -0700

    The VB version includes an update on ADOc technology with a bent toward
    converting to ADO.NET. It does not address PowerBuilder issues (at all).
    The topics are built around real-world problems and their solutions. 

    -- 
____________________________________
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.
__________________________________
"billyb" <billyb@discussions.microsoft.com> wrote in message
news:35106654-A051-4969-8C7D-80DFF1BD1AAB@microsoft.com...
> Hi Bill,
>
> After looking at the TOC of your book, I have two questions:
>
> 1) Is the ADO stuff (minus the Dot NET) relevant if I'm exclusively in
.NET and am coming from a different background (PowerBuilder)?  Just don't
want to waste time reading it if it's not.
>
> 2) I want to be sure the the topics deal with "real world" examples and
situations such as those I describe in my post.  (It looks like it, but
before I drop some more personal $ I want to be sure.)
>
> Thanks for the helpful post.
> Billy
>
>
> "William (Bill) Vaughn" wrote:
>
> > Yes Billy,
> >     There are a lot of books out there that don't use best practices. My
> > books discuss the problems with these practices and discuss the
> > architectural issues you've raised.
> >     As the other folks have said, ADO.NET (and ADO in general) is an
"OSFA"
> > interface (one-size-fits-all). It's designed to permit (fairly)
low-level
> > data access to a variety of backend data access servers and
architectures.
> > It does not really dictate how your application is designed or
approaches
> > data access problems. It simply provides the interfaces to the backend.
Yes,
> > ADO.NET has quite a few classes to support "disconnected" architectures,
but
> > you can also build connected applications as well. I, for one don't
endorse
> > "universal" use of the DataReader as some do. I think it's expensive to
code
> > and debug and if not handled correctly leads to other issues as well.
For
> > those just starting out in .NET I agree that it's tough to know what's
> > "best". The answer is "it depends". As I said, my books talk to these
issues
> > and are designed especially for those transitioning from ADO classic.
> >
> > 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.
> > __________________________________
> >
> > "billyb" <billyb@discussions.microsoft.com> wrote in message
> > news:9F6C7908-CD64-4A32-A5BE-27D87A29137A@microsoft.com...
> > > Just finishing up reading "Pragmatic ADO .NET" from the .NET Developer
> > Series.  Most of the examples deal with single tables.  The ones that
don't
> > show a very simple relationship like Customer -> Orders.
> > >
> > > In the examples, the author seems to advocate loading tables into
> > DataTables using SELECT * queries, then defining the schemas and
> > relationships.  My DBA background is cringing at this approach because
of
> > the full table scans this would needlessly cause.
> > >
> > > Moreover, I often have relationships that depend on several tables.  I
> > understand the value of knowing the schema at the ADO .NET level but it
> > seems like it comes at a the cost of not allowing the database to do
what it
> > does best in retrieving only the rows it needs using indexes.
> > >
> > > Does ADO .NET discourage the use of complex, multi-join queries with
> > limiting WHERE conditions or am I grossly misreading things?  If I am,
can
> > someone point me to a good resource that contains real-world examples
and
> > not just simple, single-table data manipulation?
> > >
> > > Thanks in advance for any guidance or advice.
> > >
> > > Billy
> > >
> >
> >
> >
  • Next message: William \(Bill\) Vaughn: "Re: Getting rid of stored procedures"

    Relevant Pages

    • Re: Need some advice on ADO .NET
      ... For what it's worth (Bill's the author here!), ... regarding his statement about not directly using DataReaders for everything. ... > data access to a variety of backend data access servers and architectures. ... > and are designed especially for those transitioning from ADO classic. ...
      (microsoft.public.dotnet.framework.adonet)
    • Re: How to Mimic Access Externally Linked Tables using ADO?
      ... William (Bill) Vaughn ... > we could transfer, as Access does, in a query through ADO, things would go ... >> It's the query engine that does all the database IO, ... >> Microsoft MVP ...
      (microsoft.public.data.ado)
    • Re: ADO and "Bad" Dates
      ... > 6 bytes in the ADO field object. ... >> William (Bill) Vaughn ... >> Microsoft MVP ... >> Please reply only to the newsgroup so that others can benefit. ...
      (microsoft.public.vb.database.ado)
    • Re: ADO and "Bad" Dates
      ... > 6 bytes in the ADO field object. ... >> William (Bill) Vaughn ... >> Microsoft MVP ... >> Please reply only to the newsgroup so that others can benefit. ...
      (microsoft.public.data.ado)
    • Re: ADO Recordset Cache
      ... I didn't mean without using any "data access ... >Bill Morgan ... >Access database using ...
      (microsoft.public.access.formscoding)