ADO vs DAO (was Re: Advice - Learning Python as 1st Programming Language)

[Alex Martelli]

"d. savitsky" <dsavitsk at e-coli.net> wrote in message
news:E_Oj5.141793$dF.4310451 at news1.rdc1.il.home.com...
    [snip]

> > - Any good libraries for working with SQL databases?
>
> i use ado/dao on windows which is fine for access.

DAO is optimized for Access (Jet, to be precise) and has limited abilities
to work outside that.  It's a transitional technology that can be fairly
said
to be on sunset lane.  I would never advise using it, except in legacy
application programs that already tied to it anyway (like all old
technologies,
it will no doubt hang around for decades to come, perhaps with kludges
occasionally applied to enable it to do [badly] certain things it was never
designed for:-).

ADO, on the other hand, is an actively-maintained, fast-growing, utterly
strategical technology for Microsoft -- the most application-programmer
visible layer of their crucial "Universal Data Access" strategy (OLE/DB is
a lower layer of UDA, too).  If an application has no need for portability
outside the Windows platform, UDA is *most* definitely the Royal Road
to data access I would advise it to rely on -- most likely through ADO
(direct OLE/DB implementation is only worth it in special cases, IMHO).
I find it a very good, extensible, solid architecture, quite well-designed
and no doubt with a long useful life to come (I'm willing to bet that the
data access model for .NET is a development of ADO, though I haven't
heard about it -- maybe they called it "ADO#" or "ADO+" or "ADO.NET"?-).

Microsoft marketing must be credited with Yet Another Memorable
Botch for having DAO and ADO use two such easily-confused acronyms,
IMHO.  But don't let their silly mistakes confuse y'all!-)


Python should be able to access DAO reasonably easily (haven't tried)
and is surely excellent at ADO work (I _have_ tried that:-).  But since a
Python application one is starting to write today surely isn't "legacy",
I think it would be FAR wiser to base it on ADO than on DAO.  (ODBC
is another possibility, but ADO is better _except_ for portability issues;
maybe someone [such as me:-)] should write a Python Database API
compliant Python package based on ADO... hmmmm....).


Alex