Office's Access XP ODBC DBI from PythonWin
aleaxit at yahoo.com
Fri Jun 15 08:05:45 EDT 2001
"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
> > > > 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...).
More information about the Python-list