Re: DAO vs ADO: question-1




"William (Bill) Vaughn" <billvaNoSpam@xxxxxxxxx> wrote in message
news:O5yP6X2yFHA.2212@xxxxxxxxxxxxxxxxxxxxxxx
> Interesting, VERY interesting. You came to the conclusion that "VB.NET"
was
> only for Web applications. Ah, it's not. VB.NET is designed to work with
the
> .NET Framework which can work with any application topology from
independent
> Windows applications, to hand-held PC apps, to client/server applications,
> to ASP.NET applications to web services and beyond.
>
> Frankly, and I'm sure many will agree that ADO classic (or ADO.NET) can't
> really help performance by itself. What can help performance in many cases
> is better application and database design. Switching from DAO to ADO is
> probably a good idea if you're worried about using dated technology, but
> both DAO and ADO (and ADO.NET) all wait at the same speed. It's not how
fast
> you ask the question, it's how long it takes to answer it. Executing a
query
> more quickly won't help if it's a poorly engineered query.
>
> hth
>
> --
> ____________________________________
> William (Bill) Vaughn
> Author, Mentor, Consultant
> Microsoft MVP
> www.betav.com/blog/billva
> www.betav.com
> www.sqlreportingservices.net
> Please reply only to the newsgroup so that others can benefit.
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> __________________________________
>
>
> "John S" <nospam> wrote in message
> news:Of7C$xqyFHA.3892@xxxxxxxxxxxxxxxxxxxxxxx
> > Hi William,
> >
> > Many articles suggest us to move from
> > DAO to ADO in order to get better performance
> > and flexibility. Since this will be a great job
> > for me, first, I must be sure if I will get much
> > conversion benefit. I am making several trials
> > to prove it.
> >
> > My app is not web-base, so I do not need
> > VBNet at the moment. I love COM very much.
> >
> > John S
> >

John,

To amplify on Mr. (Bill) Vaughn comments.

When you read various articles on M$ technologies, you must always consider
the time the article was written, ie, the historical context. Things change
and MS occasionally changes their mind. There are numerous technologies
affect by this phenomena.

When MS release ADO they said DAO was 'dead'. They even mentioned a couple
of times that there would be no further upgrades to DAO (2.x). Many authors
picked this up and spread the word. Meanwhile, many developers stuck with
DAO because it was faster in many client/server situations (specifically
Jet) and they didn't need the extra benefits/features of ADO. Then lo and
behold a couple of years ago MS released an updated DAO (3.x)!

I would say that unless you have some serious reason to upgrade and are not
looking to improve or modify your design (as Mr. Vaughn has suggested) then
I wouldn't go there.

Perhaps, you might want to apply ADO to newer development.

-ralph



.



Relevant Pages

  • Re: ADO and the Find method
    ... You cannot compare DAO and ADO. ... database, which has OLEDB provider. ... >>>> Opening of the whole table was not a good design anytime. ...
    (microsoft.public.vb.database.ado)
  • Re: Database access sucks!
    ... I don't agree with you about DAO though, you should NOT use DAO - it sucks. ... .Net changed a lot from DAO, ADO, and OLEDB. ... > a Recordset object as it was in the older versions within .NET and it ... > and I still used the old components for these applications. ...
    (microsoft.public.dotnet.general)
  • Re: error codes
    ... DAO and ADO were designed to solve two different problems. ... The DAO object model is designed specifically for the Microsoft Jet database ... its architectural design poses some problems when using the ...
    (microsoft.public.vb.database.ado)
  • Re: DAO vs ADO: question-1
    ... only for Web applications. ... Windows applications, to hand-held PC apps, to client/server applications, ... and I'm sure many will agree that ADO classic can't ... is better application and database design. ...
    (microsoft.public.vb.database.ado)
  • Re: Problems inserting records
    ... I am confused by the DAO vs ADO approach. ... table in design view, and make sure the field's Indexed property (lower pane ... But the error message you reported suggests you have another table where the ...
    (microsoft.public.access.modulesdaovba)

Loading