Python and Sybase

[Alex Martelli]

John J. Lee <jjl at pobox.com> wrote:
   ...
> > ...except that you may need to use different placeholders in SQL strings
> > for parameters to insert (sigh)...
> 
> ...and there are of course variations in SQL from DBMS to DBMS...

Yeah, _those_ I'm resigned to.  No language can paper over them.  But a
language shouldn't ADD difficulties such as placeholder differences.


> IIRC, Steve Holden suggests in his book [1] the use of
> internationalization (i18n) tools (eg. gettext) to make DB API code
> portable.  Seems unfortunately apt.
> 
> [1] "Python Web Programming", New Riders (2002)

Superb book, though unfortunately dated "pythonwise".  I was a technical
reviewer for it and loved the experience -- and when I wanted to give
Anna, at the time my long-lost and recently-reconnected friend, a
birthday gift consonant to her nascent interest in Python, that's the
book I had Amazon deliver to her door.  Since she's now my wife, and a
Python enthusiast, it seems to have worked.  It's particularly great in
terms of the lightweight but useful coverage it gives on so many things,
from E/R design to HTTP and other protocols.

But on that one detail I beg to differ from my good friend Steve.
Dropping down to string-substitution is not really the best way to solve
SQL discrepancies among RDBMS's.  Unfortunately, what I developed for
the purpose was a "work for hire", and to this day remains proprietary
to the firm I developed it for (think3 inc, if you must know) -- when I
resigned, one part of our verbal agreements was that they'd opensource
certain parts of their SW (mostly infrastructure aspects I had
developed) and I'd freely take them over and maintain them on
sourceforge or the like... they never followed through and I got tired
of pressuring them.  Next time I should need that kind of thing from an
employer or client, I'm gonna get it in writing:-).

Anyway, the solution was born back in the day where we had to add
Informix to Ingres (or was it vice versa?) in the set of RDBMSs
supported by our ancillary applications (main applications were in the
CAD field for mechanical engineering, but RDBMS access was needed by
helper applications doing Bills of Materials and the like).  Rather than
kludging it up as I was requested to do, I veered off on my own and made
up a more general solution -- part of my motivation was that I owned a
license of Watcom SQL and wanted to be able to develop at home using
that, even though supporting it was of no interest to the firm.  To make
a long story short, it worked -- it basically reimplemented the original
Relational model, quite independent of SQL _as a language_, and
generated SQL on the fly (well, not quite on-the-fly, it was done
offline) in the required dialect.  I remember later ports to such
'alien' RDBMSs as Oracle, Jet (aka [incorrectly] 'Access'), and SQL
Server, taking 1/4 the time management reasonably expected them to
(that's how I got to goof off on Usenet for 2/4ths of that time, and
still deliver in 3/4 of the time and look good;-).

But it's all captive, closed-source, proprietary stuff now.  Sigh....


Alex