Office's Access XP ODBC DBI from PythonWin

[Alex Martelli]

"M.-A. Lemburg" <mal at lemburg.com> wrote in message
news:mailman.992600484.5506.python-list at python.org...
    ...
> Benjamin Schollnick wrote:
> >
> > > mx.ODBC
> > > instead
> > > > of ODBC? If you don't plan commercial use it is free, and I can
certainly
> > > > recommend it for ease of use.
> > >
> > > Seconded.  But a minimally-working free odbc would still be
> > > a good thing IMHO.  Say I write utilities to be internally
> > > used here at work (commercial use by mx's terms).  As long
    ...
> > I was told point blankly by Marc that even though I was using MxODBC,
> > for my own non-commercial projects, that since I was using it at work
> > it had to be commercially licensed.... Even though the app was not be
> > distributed, and just a simple CGI script...
>
> How is this different from using say WinZIP in a commercial
> environment ?

I completely agree that it IS no different!  That's exactly why
I think we need the equivalent of PowerArchiver (see, e.g.,
http://www.powerarchiver.com) -- well, PA is not "minimal", but
I hope the parallel is suggestive anyway.

> 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...


> > 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...).


Alex