Office's Access XP ODBC DBI from PythonWin

[M.-A. Lemburg]

Alex Martelli wrote:
> 
> > I believe that the mxODBC license is very liberal
> > compared to other commercial software (usage is free for private
> > use, you get the complete source code, etc.) and certainly not
> > too expensive for a company to license.
> 
> Absolute agreement.  But the issue I have in mind is: Fred Smith
> is all fired up about using his newfound Python skills to make
> a little utility for company internal use, which needs to access
> various corporate and departmental databases.  He tries doing it
> with the free odbc, but that one keeps crashing -- forget it.  So
> he faces a choice:
>     a. doing it with ADO, using the freely downloadable win32all
>         extensions and freely downloadable MSDAC
>     b. convincing the boss to pay for an mxODBC license
> Advantage of [b] is getting sourcecode AND being able to run the
> resulting utility on Linux boxes.  Advantage of [a] is, Fred can
> get right down to programming and avoid the boss-convincing step.
> 
> If Fred is REALLY REALLY *VERY* KEEN to have sourcecode to all
> he uses, he may try [b] -- and may be or not be able to convince
> the boss.  Most Freds in this world, I fear, will go for the
> easier choice of [a] instead.  Most bosses are Windows-heads
> anyway and, for an utility that's not going to be a revenue
> generator for the company anyway, will instantly pick [a], too.
> 
> If the free odbc didn't crash quite SO much, maybe it could be
> kept as a viable c. choice -- and help in a tiny way to make
> Linux boxes (and maybe free BSD variants too:-) more viable...

If Fred doesn't need maintained and supported software, then
he could stick with mxODBC 1.1.1 which still is around. That's
free for commercial inhouse usage too, but the setup is somewhat
more difficult (no distutils support) and the version is
no longer being actively maintained.

> > > I don't mind that, I can understand where he was coming from... But
> > > win32's ODBC code seems to work fine for our purposes, and should still
> > > be developed....or maintained...
> > >
> > > MxODBC can't be the only ODBC code out there.....
> >
> > ODBC is *very* complicated and maintaining an interface for it
> > to make the user experience a painless one *very* time consuming.
> 
> You are surely right on this (which underscores Microsoft's
> wisdom in not-so-opaquely divorcing themselves from ODBC in
> a gradual way and pushing for their Ole/DB-ADO approach...).

They are not having much fun with their new standards either --
just look at how often they have switched technologies and
interfaces in the last few years. ODBC, OTOH, is getting better
and faster and the old prejudice of ODBC being slow is no
longer true. In fact, many DB vendors have switched to ODBC
as their native C level API. IBM with DB2 is a prominent example.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/