From Midha_Sanjeev/ny_technology@explorer.siny.com  Thu Apr  1 00:32:12 1999
From: Midha_Sanjeev/ny_technology@explorer.siny.com (Midha_Sanjeev/ny_technology@explorer.siny.com)
Date: Wed, 31 Mar 1999 19:32:12 -0500
Subject: [DB-SIG] mxodbc & mxdatetime
Message-ID: <H000007a02dd1d43@MHS>

We downloaded mxdatetime v 1.2.0 and mxodbc  v1.01 modules and 
installed it on win32 machine (NT as well as 98 & 95).

I am getting following error while importing MxDateTime module .
===================== Beging Error Stack ==========================
Traceback (innermost last):
  File "<interactive input>", line 1, in ?
  File "C:\Program Files\Python\DateTime\__init__.py", line 20, in ?
    from DateTime import *
  File "C:\Program Files\Python\DateTime\DateTime.py", line 8, in ?
    from mxDateTime import *
  File "C:\Program Files\Python\DateTime\mxDateTime\__init__.py", line 7, in ?
    from mxDateTime import *
ImportError: DLL load failed: The specified procedure could not be found.
===================== End Error Stack ===========================

Similarly trying import odbc module and getting the following error message

===================== Beging Error Stack ==========================
Traceback (innermost last):
  File "<interactive input>", line 1, in ?
ImportError: DLL load failed: The specified module could not be found.
===================== End Error Stack ==========================

Similarly trying import ODBC.MySQL module and getting the following 
error message

===================== Beging Error Stack ==========================
Traceback (innermost last):
  File "<interactive input>", line 1, in ?
NameError: Case mismatch for module name ODBC
(filename C:\Program Files\Python\win32\odbc.pyd)
===================== End Error Stack ==========================


Based on ur instructions, looks like I need to compile the modules 
using vc++, but I am having difficulty compiling the same.

IS THERE ANYWAY I COULD get COMPILED Distribution of the above


Appreciate your help...

Thanks
Sanjeev



From gstein@lyra.org  Thu Apr  1 01:44:31 1999
From: gstein@lyra.org (Greg Stein)
Date: Wed, 31 Mar 1999 17:44:31 -0800
Subject: [DB-SIG] Remaining issues with DB API 2.0
References: <Pine.LNX.4.10.9903311247080.12157-100000@kenny.comstar.net> <37028012.3AB3D8A7@lemburg.com>
Message-ID: <3702CF7F.7F407DB7@lyra.org>

M.-A. Lemburg wrote:
> 
> Andy Dustman wrote:
> >
> > eOn Wed, 31 Mar 1999, M.-A. Lemburg wrote:
> >
> > > To make testing for "multiple result sets supported" possible,
> > > I think this API should be an optional method like .rollback:
> > > either not be defined (giving an AttributeError) or raise
> > > a NotSupportError... which brings us to the next point ;-)
> > >
> > > · Should we add NotSupportedError as subclass of OperationalError ?

Nope. IMO, there are already too many exceptions, and some of them are
rather unclear on how they are distinguished from one another.

> > >
> > > · Is there a strong need for "capability testing" other than using
> > >   hasattr() ?

Nope.

> >
> > I have no objections to making it an optional method. As for other
> > capability testing, I need to think that any program that relies upon some
> > capabilty to function is simply going to break (hopefully in an obvious
> > way) when it uses a database which doesn't have the capability in
> > question.
> 
> Ok. Greg ?

I think it should be "optional void behavior, returning None". The lack
of a nextset() will probably not utterly break an application like lack
of a rollback. The thing here is that a nice behavior exists for nextset
when it isn't available: simply return None (which also happens to mean
"no more"). The semantics of its presence also match the semantics of
its absence.

I say leave the bugger in.

> 
> > [...]
> >
> > This should not actually be part of the specification, but perhaps we need
> > a design note, or guidelines for designing applications so that they can
> > ported between different databases with a minimum of effort. This makes
> > your application more resilient to changes in the DB API as well (though
> > it's hardly affecting my application, if at all, and the API shouldn't
> > change much more in the future).
> 
> Would make a nice addendum to the spec... or maybe a separate
> document. Volunteers ? Andy :-) ?

IMO, very few applications need this portability. I'd definitely ask
that it be a second document, published in the db-sig area.

Review the apps that you have: how many were written to be truly
portable? Is your SQL portable? How about those column types? etc. I
know mine aren't, so I'm specifically anti-volunteering to do this :-)

Cheers,
-g

--
Greg Stein, http://www.lyra.org/


From gstein@lyra.org  Thu Apr  1 01:47:56 1999
From: gstein@lyra.org (Greg Stein)
Date: Wed, 31 Mar 1999 17:47:56 -0800
Subject: [DB-SIG] Remaining issues with DB API 2.0
References: <Pine.LNX.4.10.9903311247080.12157-100000@kenny.comstar.net>
Message-ID: <3702D04C.6672E2CE@lyra.org>

Andy Dustman wrote:
> ...
> All of which leads us back to connect(), which we have now established
> (yay) is completely database-dependent, so we acknowledge that interface
> can't cover everything, which is no real embarassment. This really means
> that there should be some design principles involved in writing database
> applications.
>...
> The result of this is, I really only have one module in the system that I
> have to modify. If I really wanted to, I could make a new module (or
> convert to a package) and subclass only a few methods to make it
> compatible with the new database. But then, I shouldn't be depending on
> either hasattr() for capability testing; I should RTFM. Some rewriting
> when switching databases is going to be inevitable, even if I'm using the
> same interface (i.e. mxODBC).

Yes!

All excellent points, and this is precisely why I view the task of the
DBAPI to be "make them similar enough to allow Python programmers to
easily jump from one to the next" rather than "all database interaction
is truly portable".

For the latter, you can't even use SQL despite its "standardization".

Cheers,
-g

--
Greg Stein, http://www.lyra.org/


From gstein@lyra.org  Thu Apr  1 01:52:45 1999
From: gstein@lyra.org (Greg Stein)
Date: Wed, 31 Mar 1999 17:52:45 -0800
Subject: [DB-SIG] Remaining issues with DB API 2.0
References: <Pine.LNX.4.04.9903290119511.8239-100000@kenny.comstar.net>
Message-ID: <3702D16D.51AF1630@lyra.org>

Andy Dustman wrote:
>...
> Even so, I'm not sure how we would wrap dbm, gdbm, or bsddb to be
> compatible with the API, as they have no query language, no (or one)
> table, and no columns! Perhaps the wrapper could parse a little SQL,
> ignore the specified columns, and just pickle whatever parameters it
> finds. It'd be tough, though. I think I'd stick with the shelf
> interface... (I actually have a module, SQLDict, that wraps a
> dictionary-like interface around a DBI-compatible connection object...
> That direction of abstraction is a little easier to do...)

"SIG on Tabular Databases in Python

This list is intended to work through and resolve issues related to
tabular database access from Python. Being somewhat related, this list
may also cover persistency issues in Python."

If somebody wants to build a little tabular database on top of *dbm,
then DBAPI is fine. Note that DBIAPI actually does not require the use
of SQL. The execute() method refers to "operation object".

db = gjsdbm.connect('myfile')
curs = db.cursor()
op = gjsdbm.KeyLookup(key='id')
count = curs.execute(op, (123,))
print '123:', count
count = curs.execute(op, (456,))
print '456:', count

This is all quite valid using the DBAPI :-).

Cheers,
-g

--
Greg Stein, http://www.lyra.org/


From gstein@lyra.org  Thu Apr  1 02:36:17 1999
From: gstein@lyra.org (Greg Stein)
Date: Wed, 31 Mar 1999 18:36:17 -0800
Subject: [DB-SIG] Remaining issues with DB API 2.0
References: <36FBA6D4.A6511A1@lemburg.com> <36FE03DA.1646520@lyra.org> <36FE43BB.6A1F45A2@lemburg.com>
Message-ID: <3702DBA1.7F4278B7@lyra.org>

M.-A. Lemburg wrote:
>...
> The differentiation between date, time and timestamp is needed
> simply because they point to three different informations. A single
> date constructor + corresponding type object is not enough for
> a module to decide whether to take only the date, the time, or
> both parts to format some data to pass to the database.
> 
> Take e.g. a module that uses literal SQL statement formatting
> for interfacing. Such a module would not be able to tell
> whether to format a date as time only value, timestamp or
> date only value. If it were to always pass in timestamp values,
> the database would probably raise an error for DATE and TIME
> columns.
> 
> So dropping the two constructors renders that kind of interface
> useless. Becides, explicitly using the constructors in you
> database interface script will surely make them more readable :-)

Your constructors aren't sufficient anyhow(!). As I pointed out once
before, MySQL has many more varieties than a simple DATE, TIME, and
TIMESTAMP. Hell, the TIMESTAMP has about six varieties.

However, I do believe that MySQL can always take a fully-qualified
date/time and will trim it back as necessary. This implies a single
constructor.

What is the case for ODBC? Do you actually need to *bind* these
differently? (which is the major reason to have these constructors --
input binding!)

> As for the type objects: we could group date/time values
> collectively under DATETIME. Would that be in your interest ?

This would certainly be better. I wouldn't really have a problem if we
said that a "column type" of dbmodule.DATETIME existed. There may be
many *Python* types which compare equal to that, but those subtypes are
at the discretion of the module implementor.

I also believe that if a particular database module requires additional
granularity for *input* types, then it will have additional constructors
beyond the 6-tuple and the ticks.

A real problem that we're having here is that we don't have a sufficient
review of the extensions that have been made for the different
databases. What have module implementors needed to do to get their
modules to work? (not just to operate nicer, but to *work*)

> > * the 'qmark' paramstyle should not be assumed. All 2.0 DBAPI modules
> > must specify the paramstyle attribute (along with apilevel and
> > threadsafety). Further, the 'qmark' style is not the best style. Named
> > or positional are best, because they allow you to use the same parameter
> > multiple times without requiring the user to respecify it over and over.
> > For example: "select column_a1, column_b1 from a, b where a.key = :1 and
> > b.key = :1". If anything, we should recommend not using the qmark style
> > if a module implementor has a choice.
> 
> True. I'll take those comments out.

I would like to see a stated preference for 'numeric', 'named', and/or
'pyformat'. They are marginally clearer, and easier to use.

> > * a note needs to be added to execute() and executemany() to state that
> > parameters should not require any preprocessing before being passed. To
> > the client programmer, the interface should appear as if a value is
> > going to be "bound" to the input, rather than substituted into the query
> > string.
> 
> Not sure, why you want this. The spec already says:
> "Parameters may be provided as sequence or
>  mapping and will be bound to variables in the operation."

I see that, but people have still written substitution-based modules
rather than binding-based modules. Can we have a footnote on the word
bound, that reads: "The term "bound" refers to the process of binding an
input value to a database execution buffer. In practical terms, this
means that the input value is directly used as a value in the operation.
The client should not be required to "escape" the value so that it can
be used -- the value should be equal to the actual database value."

(edit the text as required and/or others may have suggested edits)

> > * I do not understand the difference between OperationalError and
> > ProgrammingError. The examples seem to divide the two exceptions
> > arbitrarily. What is the "rule" for deciding which is which?
> 
> OperationalErrors are all types of errors that are related
> to things that are not necessarily under the control of the
> programmer, e.g. lost connections, log full, transaction
> could not be performed due to lack of memory or lack of
> functionality, etc.
> 
> ProgrammingError refer to things that are under the programmers
> control, e.g. he uses a table that does not exist, he specifies
> the wrong number of parameters for a statement, uses wrong
> SQL syntax, etc.

All right. How about this: under "OperationalError" it states "data
source name not found". Whose fault is that? The programmer for entering
a typo'd DSN, or the administrators for not configuring it?

Under ProgrammingError, it states one case is a "table not found." That
isn't the programmer's fault cuz somebody deleted the table. Oh, but
maybe it is because he misspelled the table name.

Oh, and how is the InternalError different than OperationalError? Not my
fault the cursor died on me.

If I pass an integer that is too large, is that a ProgrammingError or a
DataError?

The differences here are too fine-grained to be usefully delineated in
the specification. We should probably cut the number of exceptions in
half.

> Hmm, maybe OperationalError wasn't the right choice for
> the dynamic .rollback() error after all...
> 
> There is some overlap and in fact some DBs raise ProgrammingErrors
> for certain things while others use OperationalError. Maybe we
> should make one a subclass of the other... ?

I'd say we make two subclasses of Error: InterfaceError, and
DatabaseError.

> > * I still do not understand the presence of the rowcount attribute.
> > *Especially* since the execute() method now says "return value
> > undefined." That's bogus. Let's nuke the rowcount attribute and return
> > *that* value from execute. No reason to do an execute and then go
> > somewhere else for this information.
> 
> The "return value undefined" was done to allow the .execute()
> method return the old style return value (which is not easily
> implementable for various reasons I already pointed out in
> previous mails). The module implementor is free to return
> whatever he likes.
> 
> The rowcount definition is somewhat different from the 1.0
> return value spec of .execute(). That's why it's a new attribute.
> Again, module implementors could go and simply have .execute()
> return whatever the value of .rowcount would be if they like...

If we make it undefined, then we are stating that in DBAPI 2.0, it
cannot be used (without consulting the db-specific doc). In other words:
somebody has to update their client program.

If they are going to update their program, then let's make execute()
return something rational.

> > * for the execute() return value (merged from the rowcount thing), we
> > should discriminate between "I know the number and it is X" and "I have
> > no idea". The latter should be None. Note that -1 no longer applies
> > since the value is only available as part of an execute, rather than a
> > random-access. I agree with your earlier comments about needing to
> > remove the bit about detecting DML vs DDL vs DQL. I like your current
> > text, with the additions of "0 or None for DDL statements" and "None for
> > cases where the count cannot be determined".
> 
> The problem with None is that it compares false which would
> be ok for DDL (0 or None both are false), but fails to indicate
> "don't know" for DQL where 0 could be a possible known row count.

If people are looking for None, then they can use "is None" rather than
"not".

true-ness / false-ness is obviously not the appropriate way to
discriminate the values.

result = curs.execute(op)
if result is None:
  # database doesn't know how many rows were returned/affected
elif result == 0:
  # no rows returned/affected
else:
  # some positive number of rows were returned/affected

For DDL: a database will return 0 or None (whichever is convenient)
For DML: a database will return >=0 or None (if it can't determine the
number of rows affected... at one time, PostGres couldn't)
For DQL: a database will return >=0 or None (if it can't determine the
number of rows returned until a fetchXXX() is performed)

A footnote with the above three lines would be a handy "implementation
hint" for developers. I believe it also fits in with your need to not be
required to parse the statement (which I agree is something to avoid!).

> As for the random-access vs. return value: some DBs could be
> able to calculate the row count only if at least one fetch was
> done. So the information might not be available right after the
> execute.
> 
> How about defining the return value .execute() as being the
> current .rowcount attribute's value as you propose and provide
> the .rowcount as additional, possibly optional feature ?

Drop rowcount altogether. We don't need multiple ways to access the
value.

> > * the comment in fetchone() about the underlying cursor should be
> > removed. The Python programmer can never access that thing, so the
> > comment is irrelevant. The comment about using array fetches and whatnot
> > still apply -- in particular, the possible use of the arraysize
> > attribute.
> 
> The comment is simply a warning to those who might expect the
> fetchone() method to move the cursor by one row. This may be
> true for some interfaces (e.g. mxODBC) while being false for others.

Understood, but why does the Python programmer care about this? It has
no bearing on the interface since they have NO access to that cursor.
The fact that it does or does not move forward N rows is moot -- the
Python programmer only uses the DBAPI interface which has no "movement"
semantics.

Could this note be moved under the implementation hints?

> > * in all methods that state "an exception is raised..." we should state
> > *which* exception. We have a complete set defined at the beginning, so
> > this makes sense to do. I would recommend InterfaceError (it is based on
> > the interface we provide, rather than the underlying database). Hrm.
> > Maybe not. I can see a case where the DB module will simply attempt to
> > call the underlying DB function and generate a DB-related exception.
> > Thoughts anyone?
> 
> This is hard to do, since the types of errors may very well be
> the whole range of possible Python exceptions + the ones defined
> in the DB API, e.g. a conversion routine might raise an OverflowError
> in case of numeric overflow while raising an InterfaceError in
> case a certain internal assertion failed.

Good point. I retract my request :-)

> > * on nextset(), it might be nice to define a return value that allows
> > the user to discriminate these types of results: no more sets (None
> > right now); another set with N rows; another set with unknown number of
> > rows. The only thing really available for the last one is a negative
> > number (e.g. -1), but that seems a bit hokey. Any ideas?
> 
> I've got no experience with multiple result sets, but do that there
> was a point to define the return value in the fuzzy way it is
> written in the spec.

I think it would be useful to have a specified return value, much like
we have it for execute(). Strictly speaking, a nextset() is much like
execute, but meaning "give me the next part of my operation" ... the
client wants to know the results.

Can we mark this as an open issue? Maybe somebody will have a good idea.

Ooh. I have a proposal: maybe we can have a global named unknownCount.
This can be returned by execute() and by nextset(). In both cases, it
means "I have no idea". Client programmers should test with an "is"
rather than equivalence.  Oh, actually, if the underlying type does not
specify a cmp() function, then a "==" compares the type name... this an
"==" will work for client programmers, too, since the only other return
value is a number. (would we still have None as acceptable? ... oh, for
nextset(), yes).

New comment: should we change the globals to be: apiLevel, threadSafety,
and paramStyle? Or maybe underscore-separated? Or leave them?  hmm... I
think "Python style" says all lower-case for these, mixed signal on the
underscore. Thoughts?

Cheers,
-g

--
Greg Stein, http://www.lyra.org/


From adustman@comstar.net  Thu Apr  1 05:48:48 1999
From: adustman@comstar.net (Andy Dustman)
Date: Thu, 1 Apr 1999 00:48:48 -0500 (EST)
Subject: [DB-SIG] Remaining issues with DB API 2.0
In-Reply-To: <3702DBA1.7F4278B7@lyra.org>
Message-ID: <Pine.LNX.4.10.9904010027460.13974-100000@kenny.comstar.net>

On Wed, 31 Mar 1999, Greg Stein wrote:

> However, I do believe that MySQL can always take a fully-qualified
> date/time and will trim it back as necessary. This implies a single
> constructor.

Apparently not totally true. M-A and I tested this, and if you pass MySQL
a TIMESTAMP with a fractional seconds part, it treats that as an illegal
value and sets it to zero. Nuisance. This is true at least with 3.22.19a.
I have not tested against 19b.

> I would like to see a stated preference for 'numeric', 'named', and/or
> 'pyformat'. They are marginally clearer, and easier to use.

Are there any databases where the parameter marker is actually an option?
I suppose you could use whatever you wanted for MySQL, but it is vastly
easier to use 'format' and/or 'pyformat'.

> The client should not be required to "escape" the value so that it can
> be used -- the value should be equal to the actual database value."

I.e., the module should do any escaping, correct? If true, I agree.

> I'd say we make two subclasses of Error: InterfaceError, and
> DatabaseError.

Speaking of which, I can't find a obvious way in the Python API to create
an exception with multiple inheritance. Any ideas?

> > > * in all methods that state "an exception is raised..." we should state
> > > *which* exception. We have a complete set defined at the beginning, so
> > > this makes sense to do. I would recommend InterfaceError (it is based on
> > > the interface we provide, rather than the underlying database). Hrm.
> > > Maybe not. I can see a case where the DB module will simply attempt to
> > > call the underlying DB function and generate a DB-related exception.
> > > Thoughts anyone?
> > 
> > This is hard to do, since the types of errors may very well be
> > the whole range of possible Python exceptions + the ones defined
> > in the DB API, e.g. a conversion routine might raise an OverflowError
> > in case of numeric overflow while raising an InterfaceError in
> > case a certain internal assertion failed.
> 
> Good point. I retract my request :-)

This is why I would like to find a way to do multiple inheritance on
exceptions in the Python C API...

> New comment: should we change the globals to be: apiLevel, threadSafety,
> and paramStyle? Or maybe underscore-separated? Or leave them?  hmm... I
> think "Python style" says all lower-case for these, mixed signal on the
> underscore. Thoughts?

My reading of the style guide suggests lower-case, no underscores. 

-- 
Andy Dustman  (ICQ#32922760)    You should always say "spam" and "eggs"
ComStar Communications Corp.                 instead of "foo" and "bar"
(706) 549-7689 | PGP KeyID=0xC72F3F1D   in Python examples. (Mark Lutz)



From mal@lemburg.com  Thu Apr  1 08:27:17 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 01 Apr 1999 10:27:17 +0200
Subject: [DB-SIG] mxodbc & mxdatetime
References: <H000007a02dd1d43@MHS>
Message-ID: <37032DE5.59063282@lemburg.com>

Midha_Sanjeev/ny_technology@explorer.siny.com wrote:
> 
> We downloaded mxdatetime v 1.2.0 and mxodbc  v1.01 modules and
> installed it on win32 machine (NT as well as 98 & 95).
> 
> I am getting following error while importing MxDateTime module .
> ===================== Beging Error Stack ==========================
> Traceback (innermost last):
>   File "<interactive input>", line 1, in ?
>   File "C:\Program Files\Python\DateTime\__init__.py", line 20, in ?
>     from DateTime import *
>   File "C:\Program Files\Python\DateTime\DateTime.py", line 8, in ?
>     from mxDateTime import *
>   File "C:\Program Files\Python\DateTime\mxDateTime\__init__.py", line 7, in ?
>     from mxDateTime import *
> ImportError: DLL load failed: The specified procedure could not be found.
> ===================== End Error Stack ===========================

This is probably because you are using Python <1.5.2b2. I suggest
upgrading to the latest version (in older versions the APIs
PyString_InternXXX() were not properly exported in the WinXX DLL).

The alternative is recompiling. The mxpyapi.h header file should
then apply the following fix automatically:

/* These are missing from PC/python_nt.def and thus didn't get included
   in python1.5.lib on Windows platforms. */
#ifdef MS_WIN32
# define PyString_InternInPlace(x)
# define PyString_InternFromString(x) PyString_FromString(x)
#endif


> Similarly trying import odbc module and getting the following error message
> 
> ===================== Beging Error Stack ==========================
> Traceback (innermost last):
>   File "<interactive input>", line 1, in ?
> ImportError: DLL load failed: The specified module could not be found.
> ===================== End Error Stack ==========================

mxODBC uses mxDateTime, so you get the same error here.

> Similarly trying import ODBC.MySQL module and getting the following
> error message
> 
> ===================== Beging Error Stack ==========================
> Traceback (innermost last):
>   File "<interactive input>", line 1, in ?
> NameError: Case mismatch for module name ODBC
> (filename C:\Program Files\Python\win32\odbc.pyd)
> ===================== End Error Stack ==========================

You have obviously installed the win32all package from Mark
Hammond. There are instructions in the docs on what to do
about the naming conflict (there is an odbc module in win32all
too; it's a different one, though).

> Based on ur instructions, looks like I need to compile the modules
> using vc++, but I am having difficulty compiling the same.
> 
> IS THERE ANYWAY I COULD get COMPILED Distribution of the above

In about a month I expect to be developing on WinXX too, so
I'll include my own binaries in the extensions. Right now,
I'm relying on others to help me (and thereby helping others ;).

-- 
Marc-Andre Lemburg                               Y2000: 274 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From mal@lemburg.com  Thu Apr  1 09:38:13 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 01 Apr 1999 11:38:13 +0200
Subject: [DB-SIG] Remaining issues with DB API 2.0
References: <Pine.LNX.4.10.9904010027460.13974-100000@kenny.comstar.net>
Message-ID: <37033E85.54C713A1@lemburg.com>

Andy Dustman wrote:
> 
> > I'd say we make two subclasses of Error: InterfaceError, and
> > DatabaseError.
> 
> Speaking of which, I can't find a obvious way in the Python API to create
> an exception with multiple inheritance. Any ideas?

You mean: how do I create an exception having a predefined base class ?
[I don't see a need for multiple inheritance (with more than one
base class) in this situation.]

Here's an example:

/* Create an exception object, insert it into the module dictionary
   under the given name and return the object pointer; this is NULL in
   case an error occurred. base can be given to indicate the base
   object to be used by the exception object. It should be NULL
   otherwise */

static 
PyObject *insexc(PyObject *moddict,
		 char *name,
		 PyObject *base)
{
    PyObject *v;
    char fullname[256];
    
    sprintf(fullname,MXODBC_MODULE".%s",name);
    v = PyErr_NewException(fullname, base, NULL);
    if (v == NULL)
	return NULL;
    if (PyDict_SetItemString(moddict,name,v))
	return NULL;
    return v;
}

e.g.

    if ((mxODBC_Error = insexc(moddict,"Error",PyExc_StandardError)) == NULL)
	goto onError;
    if ((mxODBC_InterfaceError = insexc(moddict,"InterfaceError",mxODBC_Error))
	== NULL)
	goto onError;


Was that what you meant ?

-- 
Marc-Andre Lemburg                               Y2000: 274 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From mal@lemburg.com  Thu Apr  1 09:31:33 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 01 Apr 1999 11:31:33 +0200
Subject: [DB-SIG] Remaining issues with DB API 2.0
References: <Pine.LNX.4.10.9903311247080.12157-100000@kenny.comstar.net> <37028012.3AB3D8A7@lemburg.com> <3702CF7F.7F407DB7@lyra.org>
Message-ID: <37033CF5.44802359@lemburg.com>

Greg Stein wrote:
> 
> > > On Wed, 31 Mar 1999, M.-A. Lemburg wrote:
> > >
> > > > To make testing for "multiple result sets supported" possible,
> > > > I think this API should be an optional method like .rollback:
> > > > either not be defined (giving an AttributeError) or raise
> > > > a NotSupportError... which brings us to the next point ;-)
> > > >
> > > > · Should we add NotSupportedError as subclass of OperationalError ?
> 
> Nope. IMO, there are already too many exceptions, and some of them are
> rather unclear on how they are distinguished from one another.

Actually, those exceptions all originated from the odbc module
in win32all... weren't you involved in the writing of that module ?

You have got a point there about the fuzzyness of the definitions,
I won't except the point about them being too many: since they
are layered, it is really totally up to the user and the implementor
which exceptions to catch or raise and defining exception class is
no burdon on programmers (there are simple to use APIs available)
even if they choose not to use them.

This is the current class layout:

StandardError
|__Warning
|__Error
   |__InterfaceError
   |__DataError
   |__OperationalError
   |__IntegrityError
   |__InternalError
   |__ProgrammingError

I would suggest extending the tree to allow Greg's proposed
DatabaseError to fit in:

StandardError
|__Warning
|__Error
   |__InterfaceError
   |__DatabaseError
      |__DataError
      |__OperationalError
      |__IntegrityError
      |__InternalError
      |__ProgrammingError
      |__NotSupportedError

This scheme can be extended by the programmer at will. I'll include
cut&paste code in the implementation hints section.

> > > >
> > > > · Is there a strong need for "capability testing" other than using
> > > >   hasattr() ?
> 
> Nope.

Huh :-) Didn't you bring this up ??! Nevermind, I'm not too keen
on having it either, but I do like your clean and simple method
using hasattr().

> > >
> > > I have no objections to making it an optional method. As for other
> > > capability testing, I need to think that any program that relies upon some
> > > capabilty to function is simply going to break (hopefully in an obvious
> > > way) when it uses a database which doesn't have the capability in
> > > question.
> >
> > Ok. Greg ?
> 
> I think it should be "optional void behavior, returning None". The lack
> of a nextset() will probably not utterly break an application like lack
> of a rollback. The thing here is that a nice behavior exists for nextset
> when it isn't available: simply return None (which also happens to mean
> "no more"). The semantics of its presence also match the semantics of
> its absence.
> 
> I say leave the bugger in.

That makes 2 for "apply the same procedure as for .rollback()"
and 1 for "leave it as it is defined now".

Any others who would like to jump in ?

> > > This should not actually be part of the specification, but perhaps we need
> > > a design note, or guidelines for designing applications so that they can
> > > ported between different databases with a minimum of effort. This makes
> > > your application more resilient to changes in the DB API as well (though
> > > it's hardly affecting my application, if at all, and the API shouldn't
> > > change much more in the future).
> >
> > Would make a nice addendum to the spec... or maybe a separate
> > document. Volunteers ? Andy :-) ?
> 
> IMO, very few applications need this portability. I'd definitely ask
> that it be a second document, published in the db-sig area.
> 
> Review the apps that you have: how many were written to be truly
> portable? Is your SQL portable? How about those column types? etc. I
> know mine aren't, so I'm specifically anti-volunteering to do this :-)

Oh well, on one hand we are constantly arguing in favor
of database portability, on the other we simply state "not doable
anyways". This doesn't lead anywhere, I'm afraid. The DB API should
provide all the means it can to be able to write database
portable code.

> M.-A. Lemburg wrote:
> >...
> > The differentiation between date, time and timestamp is needed
> > simply because they point to three different informations. A single
> > date constructor + corresponding type object is not enough for
> > a module to decide whether to take only the date, the time, or
> > both parts to format some data to pass to the database.
> > 
> > Take e.g. a module that uses literal SQL statement formatting
> > for interfacing. Such a module would not be able to tell
> > whether to format a date as time only value, timestamp or
> > date only value. If it were to always pass in timestamp values,
> > the database would probably raise an error for DATE and TIME
> > columns.
> > 
> > So dropping the two constructors renders that kind of interface
> > useless. Becides, explicitly using the constructors in you
> > database interface script will surely make them more readable :-)
> 
> Your constructors aren't sufficient anyhow(!).

Oh, they are w/r to what ANSI-SQL defines. The number types
can all be expressed with standard Python numbers, the character
types with Python strings and Binary() objects. All that was
left were the TIME and TIMESTAMP types.

I don't quite understand why you oppose having a bit more
variaty in the spec. It can all be coded in Python in a few
lines so there's really no big strain on the programmer.

> As I pointed out once
> before, MySQL has many more varieties than a simple DATE, TIME, and
> TIMESTAMP. Hell, the TIMESTAMP has about six varieties.
> 
> However, I do believe that MySQL can always take a fully-qualified
> date/time and will trim it back as necessary. This implies a single
> constructor.
> 
> What is the case for ODBC? Do you actually need to *bind* these
> differently? (which is the major reason to have these constructors --
> input binding!)

The main reason is to be ANSI-SQL conform. If the database
suppports other types (just have a look at Postgresql), these
are bound to be database specific extensions, yet all databases
that claim to support ANSI-SQL must provide these few basic types.

> > As for the type objects: we could group date/time values
> > collectively under DATETIME. Would that be in your interest ?
> 
> This would certainly be better. I wouldn't really have a problem if we
> said that a "column type" of dbmodule.DATETIME existed. There may be
> many *Python* types which compare equal to that, but those subtypes are
> at the discretion of the module implementor.
> 
> I also believe that if a particular database module requires additional
> granularity for *input* types, then it will have additional constructors
> beyond the 6-tuple and the ticks.

Sure, there's nothing to say against that. In fact, database
specific extensions should be welcomed. We're only trying to
settle on a basic set of features here and the guideline for this
should be ANSI-SQL and common experience with existing database
APIs, IMO.

> A real problem that we're having here is that we don't have a sufficient
> review of the extensions that have been made for the different
> databases. What have module implementors needed to do to get their
> modules to work? (not just to operate nicer, but to *work*)

Oh, we have three module implementors on-line ;-)

> > > * the 'qmark' paramstyle should not be assumed. All 2.0 DBAPI modules
> > > must specify the paramstyle attribute (along with apilevel and
> > > threadsafety). Further, the 'qmark' style is not the best style. Named
> > > or positional are best, because they allow you to use the same parameter
> > > multiple times without requiring the user to respecify it over and over.
> > > For example: "select column_a1, column_b1 from a, b where a.key = :1 and
> > > b.key = :1". If anything, we should recommend not using the qmark style
> > > if a module implementor has a choice.
> > 
> > True. I'll take those comments out.
> 
> I would like to see a stated preference for 'numeric', 'named', and/or
> 'pyformat'. They are marginally clearer, and easier to use.

Ok. I added a comment as footnote.

> > > * a note needs to be added to execute() and executemany() to state that
> > > parameters should not require any preprocessing before being passed. To
> > > the client programmer, the interface should appear as if a value is
> > > going to be "bound" to the input, rather than substituted into the query
> > > string.
> > 
> > Not sure, why you want this. The spec already says:
> > "Parameters may be provided as sequence or
> >  mapping and will be bound to variables in the operation."
> 
> I see that, but people have still written substitution-based modules
> rather than binding-based modules. Can we have a footnote on the word
> bound, that reads: "The term "bound" refers to the process of binding an
> input value to a database execution buffer. In practical terms, this
> means that the input value is directly used as a value in the operation.
> The client should not be required to "escape" the value so that it can
> be used -- the value should be equal to the actual database value."

Ok. Also added as footnote.

> > > * I do not understand the difference between OperationalError and
> > > ProgrammingError. The examples seem to divide the two exceptions
> > > arbitrarily. What is the "rule" for deciding which is which?
> > 
> > OperationalErrors are all types of errors that are related
> > to things that are not necessarily under the control of the
> > programmer, e.g. lost connections, log full, transaction
> > could not be performed due to lack of memory or lack of
> > functionality, etc.
> > 
> > ProgrammingError refer to things that are under the programmers
> > control, e.g. he uses a table that does not exist, he specifies
> > the wrong number of parameters for a statement, uses wrong
> > SQL syntax, etc.
> 
> All right. How about this: under "OperationalError" it states "data
> source name not found". Whose fault is that? The programmer for entering
> a typo'd DSN, or the administrators for not configuring it?
> 
> Under ProgrammingError, it states one case is a "table not found." That
> isn't the programmer's fault cuz somebody deleted the table. Oh, but
> maybe it is because he misspelled the table name.
> 
> Oh, and how is the InternalError different than OperationalError? Not my
> fault the cursor died on me.
> 
> If I pass an integer that is too large, is that a ProgrammingError or a
> DataError?
> 
> The differences here are too fine-grained to be usefully delineated in
> the specification. We should probably cut the number of exceptions in
> half.

No, but we should add another layer for DatabaseErrors as you
propose below (see exception layout above).

> > Hmm, maybe OperationalError wasn't the right choice for
> > the dynamic .rollback() error after all...
> > 
> > There is some overlap and in fact some DBs raise ProgrammingErrors
> > for certain things while others use OperationalError. Maybe we
> > should make one a subclass of the other... ?
> 
> I'd say we make two subclasses of Error: InterfaceError, and
> DatabaseError.

See above.

> > > * I still do not understand the presence of the rowcount attribute.
> > > *Especially* since the execute() method now says "return value
> > > undefined." That's bogus. Let's nuke the rowcount attribute and return
> > > *that* value from execute. No reason to do an execute and then go
> > > somewhere else for this information.
> > 
> > The "return value undefined" was done to allow the .execute()
> > method return the old style return value (which is not easily
> > implementable for various reasons I already pointed out in
> > previous mails). The module implementor is free to return
> > whatever he likes.
> > 
> > The rowcount definition is somewhat different from the 1.0
> > return value spec of .execute(). That's why it's a new attribute.
> > Again, module implementors could go and simply have .execute()
> > return whatever the value of .rowcount would be if they like...
> 
> If we make it undefined, then we are stating that in DBAPI 2.0, it
> cannot be used (without consulting the db-specific doc). In other words:
> somebody has to update their client program.

That depends on the module implementation. I think this part of
the spec is much like the connect() part: it is deemed to be
database dependent.

Note that a return value of "don't know" would have to be possible
for .executeXXX() otherwise and this would of course render the
return value useless, because if the method can return this value,
the database script would still not be able to rely on the return value
being meaningful.

> If they are going to update their program, then let's make execute()
> return something rational.
>
> > > * for the execute() return value (merged from the rowcount thing), we
> > > should discriminate between "I know the number and it is X" and "I have
> > > no idea". The latter should be None. Note that -1 no longer applies
> > > since the value is only available as part of an execute, rather than a
> > > random-access. I agree with your earlier comments about needing to
> > > remove the bit about detecting DML vs DDL vs DQL. I like your current
> > > text, with the additions of "0 or None for DDL statements" and "None for
> > > cases where the count cannot be determined".
> > 
> > The problem with None is that it compares false which would
> > be ok for DDL (0 or None both are false), but fails to indicate
> > "don't know" for DQL where 0 could be a possible known row count.
> 
> If people are looking for None, then they can use "is None" rather than
> "not".
> 
> true-ness / false-ness is obviously not the appropriate way to
> discriminate the values.
> 
> result = curs.execute(op)
> if result is None:
>   # database doesn't know how many rows were returned/affected
> elif result == 0:
>   # no rows returned/affected
> else:
>   # some positive number of rows were returned/affected
> 
> For DDL: a database will return 0 or None (whichever is convenient)
> For DML: a database will return >=0 or None (if it can't determine the
> number of rows affected... at one time, PostGres couldn't)
> For DQL: a database will return >=0 or None (if it can't determine the
> number of rows returned until a fetchXXX() is performed)
> 
> A footnote with the above three lines would be a handy "implementation
> hint" for developers. I believe it also fits in with your need to not be
> required to parse the statement (which I agree is something to avoid!).

But what use would this definition have: my module could always
return None and be in sync with the spec. Still, the return value
would have no value for a user of my module.
 
> > As for the random-access vs. return value: some DBs could be
> > able to calculate the row count only if at least one fetch was
> > done. So the information might not be available right after the
> > execute.
> > 
> > How about defining the return value .execute() as being the
> > current .rowcount attribute's value as you propose and provide
> > the .rowcount as additional, possibly optional feature ?
> 
> Drop rowcount altogether. We don't need multiple ways to access the
> value.

As I said: it's not just another way to get that information.
The rowcount could become available after a .fecthXXX() call,
so it's dynamic... hmm, maybe it should be turned into a
method.

> > > * the comment in fetchone() about the underlying cursor should be
> > > removed. The Python programmer can never access that thing, so the
> > > comment is irrelevant. The comment about using array fetches and whatnot
> > > still apply -- in particular, the possible use of the arraysize
> > > attribute.
> > 
> > The comment is simply a warning to those who might expect the
> > fetchone() method to move the cursor by one row. This may be
> > true for some interfaces (e.g. mxODBC) while being false for others.
> 
> Understood, but why does the Python programmer care about this? It has
> no bearing on the interface since they have NO access to that cursor.
> The fact that it does or does not move forward N rows is moot -- the
> Python programmer only uses the DBAPI interface which has no "movement"
> semantics.
> 
> Could this note be moved under the implementation hints?

Ok. It's a footnote now.

> > > * on nextset(), it might be nice to define a return value that allows
> > > the user to discriminate these types of results: no more sets (None
> > > right now); another set with N rows; another set with unknown number of
> > > rows. The only thing really available for the last one is a negative
> > > number (e.g. -1), but that seems a bit hokey. Any ideas?
> > 
> > I've got no experience with multiple result sets, but do that there
> > was a point to define the return value in the fuzzy way it is
> > written in the spec.
> 
> I think it would be useful to have a specified return value, much like
> we have it for execute(). Strictly speaking, a nextset() is much like
> execute, but meaning "give me the next part of my operation" ... the
> client wants to know the results.
> 
> Can we mark this as an open issue? Maybe somebody will have a good idea.

Ok, I'll add it to the open issues section.

> Ooh. I have a proposal: maybe we can have a global named unknownCount.
> This can be returned by execute() and by nextset(). In both cases, it
> means "I have no idea". Client programmers should test with an "is"
> rather than equivalence.  Oh, actually, if the underlying type does not
> specify a cmp() function, then a "==" compares the type name... this an
> "==" will work for client programmers, too, since the only other return
> value is a number. (would we still have None as acceptable? ... oh, for
> nextset(), yes).

Ehm,... have you had too much coffee ;-) 

What's so bad about -1, BTW ?

> New comment: should we change the globals to be: apiLevel, threadSafety,
> and paramStyle? Or maybe underscore-separated? Or leave them?  hmm... I
> think "Python style" says all lower-case for these, mixed signal on the
> underscore. Thoughts?

All the APIs use lower-case and no underscores, so I guess that's
not in sync with the rest. [Not that I like this naming scheme, but
it's the way it's been in Python for ages.]

Uff, made it... ;-)

-- 
Marc-Andre Lemburg                               Y2000: 274 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From mal@lemburg.com  Thu Apr  1 10:10:12 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 01 Apr 1999 12:10:12 +0200
Subject: [DB-SIG] Remaining issues with DB API 2.0
References: <Pine.LNX.4.10.9904010027460.13974-100000@kenny.comstar.net> <37033E85.54C713A1@lemburg.com>
Message-ID: <37034604.5EF32376@lemburg.com>

I've uploaded a new version of the API (which includes some changes
to the exception hierarchy and .nextset()):

	http://starship.skyport.net/~lemburg/DatabaseAPI-2.0.html

-- 
Marc-Andre Lemburg                               Y2000: 274 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From adustman@comstar.net  Thu Apr  1 16:57:02 1999
From: adustman@comstar.net (Andy Dustman)
Date: Thu, 1 Apr 1999 11:57:02 -0500 (EST)
Subject: [DB-SIG] Remaining issues with DB API 2.0
In-Reply-To: <37033E85.54C713A1@lemburg.com>
Message-ID: <Pine.LNX.4.10.9904011154080.20520-100000@kenny.comstar.net>

On Thu, 1 Apr 1999, M.-A. Lemburg wrote:

> Andy Dustman wrote:
> > 
> > > I'd say we make two subclasses of Error: InterfaceError, and
> > > DatabaseError.
> > 
> > Speaking of which, I can't find a obvious way in the Python API to create
> > an exception with multiple inheritance. Any ideas?
> 
> You mean: how do I create an exception having a predefined base class ?
> [I don't see a need for multiple inheritance (with more than one
> base class) in this situation.]

No, I really did mean multple inheritance. I am already using regular
single-inheritance (and I DID model off mxODBC :). I may not use multple
inheritance for this module, but I will at some point...

-- 
Andy Dustman  (ICQ#32922760)    You should always say "spam" and "eggs"
ComStar Communications Corp.                 instead of "foo" and "bar"
(706) 549-7689 | PGP KeyID=0xC72F3F1D   in Python examples. (Mark Lutz)



From mal@lemburg.com  Thu Apr  1 21:04:34 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 01 Apr 1999 23:04:34 +0200
Subject: [DB-SIG] Remaining issues with DB API 2.0
References: <Pine.LNX.4.10.9904011154080.20520-100000@kenny.comstar.net>
Message-ID: <3703DF62.546DA54@lemburg.com>

Andy Dustman wrote:
> 
> On Thu, 1 Apr 1999, M.-A. Lemburg wrote:
> 
> > Andy Dustman wrote:
> > >
> > > > I'd say we make two subclasses of Error: InterfaceError, and
> > > > DatabaseError.
> > >
> > > Speaking of which, I can't find a obvious way in the Python API to create
> > > an exception with multiple inheritance. Any ideas?
> >
> > You mean: how do I create an exception having a predefined base class ?
> > [I don't see a need for multiple inheritance (with more than one
> > base class) in this situation.]
> 
> No, I really did mean multple inheritance. I am already using regular
> single-inheritance (and I DID model off mxODBC :). I may not use multple
> inheritance for this module, but I will at some point...

Ah, ok. I guess you could add a new API to Python/errors.c
and send the patch to Guido. There currently is no way to comfortably
create exception classes with bases *tuples* (it's easy to add though).

Cheers,
-- 
Marc-Andre Lemburg                               Y2000: 274 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From adustman@comstar.net  Wed Apr  7 01:01:08 1999
From: adustman@comstar.net (Andy Dustman)
Date: Tue, 6 Apr 1999 20:01:08 -0400 (EDT)
Subject: [DB-SIG] New MySQL interface now available
Message-ID: <Pine.LNX.4.10.9904061933140.4207-100000@kenny.comstar.net>

I am happy to announce that a new Python interface to the MySQL database
server has been released. MySQLdb-0.0.0 is an all-new interface, sharing
no code with earlier interfaces. The main features are:

* conforms to DB-SIG database API version 2.0 (proposed)
* thread-safe
* thread-friendly (threads will not block each other unneccessarily)
* works with latest MySQL 3.22.20a release
* Python-esque licensing

Since it uses the DB-SIG API, it should be almost completely compatible
with MySQLmodule-1.4, aside from the connect() function.

On-line documentation is available at:

	http://starship.python.net/crew/adustman/MySQLdb.html

Please send any bug reports or suggestions to: <adustman@comstar.net>

<P><A HREF="http://starship.python.net/crew/adustman/">MySQLdb-0.0.0 -
all-new interface to MySQL database server. (06-Apr-99)</A>

-- 
andy dustman  | programmer/analyst |  comstar communications corporation
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d




From mal@lemburg.com  Wed Apr  7 17:56:23 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 07 Apr 1999 18:56:23 +0200
Subject: [DB-SIG] DB API 2.0
Message-ID: <370B8E37.5C88A557@lemburg.com>

Hi everybody,

I think the time has come and we can push out the new specification
on next Monday. Until then, there's still some cleanup to do like
reformatting, spell correction, etc.

Does anybody know how to reach Micheal McLay ? The DB sigs pages
on www.python.org will need some updates...

DB API 1.0:
      http://starship.skyport.net/~lemburg/DatabaseAPI-1.0.html

DB API 2.0:
      http://starship.skyport.net/~lemburg/DatabaseAPI-2.0.html

-- 
Marc-Andre Lemburg                               Y2000: 268 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From mal@lemburg.com  Wed Apr  7 21:27:24 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 07 Apr 1999 22:27:24 +0200
Subject: [DB-SIG] Updating the SIG pages
Message-ID: <370BBFAC.32658844@lemburg.com>

I've just uploaded a cleaned up version of the spec, it's now
at 2.0a15.

As for the SIG's web-pages: I think there should be a complete
rewrite of the SIG's status page. Since Andrew has already done
a very fine job with the database topics collection, I think that
the status page could be boiled down to a few pointers to his
collection and the two API versions.

For backward compatibility, we'll need to reference the old
API page as DatabaseAPI.html and DatabaseAPI-1.0.html. The
new one should be named DatabaseAPI-2.0.html. Future versions
can then pick up on this naming scheme.

New modules should then probably be published in Andrew's topics
guide as sole location. The current setup with some modules on the
topics pages, some on the SIG pages and yet some more in the
FTP contrib section is not too well suited to make people feel
comfortable with the available database connectivity, IMHO.

What do you think ?

BTW: Even if the SIG is meant for relational databases, wouldn't
it be a good idea to open it up for OODBs too ? What about an
OODB API (with a DB API compliant adaptor) as new target of
discussion ?!

-- 
Marc-Andre Lemburg                               Y2000: 268 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From adustman@comstar.net  Wed Apr  7 22:13:31 1999
From: adustman@comstar.net (Andy Dustman)
Date: Wed, 7 Apr 1999 17:13:31 -0400 (EDT)
Subject: [DB-SIG] Updating the SIG pages
In-Reply-To: <370BBFAC.32658844@lemburg.com>
Message-ID: <Pine.LNX.4.10.9904071709450.10447-100000@kenny.comstar.net>

On Wed, 7 Apr 1999, M.-A. Lemburg wrote:

> BTW: Even if the SIG is meant for relational databases, wouldn't
> it be a good idea to open it up for OODBs too ? What about an
> OODB API (with a DB API compliant adaptor) as new target of
> discussion ?!

It sounds like this may be the domain of the DO-SIG (distributed object),
which is working on CORBA bindings and such. That doesn't mean we can't
butt in, however. :) Does look interesting...

-- 
andy dustman  | programmer/analyst |  comstar communications corporation
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d



From akuchlin@cnri.reston.va.us  Wed Apr  7 22:32:27 1999
From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling)
Date: Wed,  7 Apr 1999 17:32:27 -0400 (EDT)
Subject: [DB-SIG] Updating the SIG pages
In-Reply-To: <370BBFAC.32658844@lemburg.com>
References: <370BBFAC.32658844@lemburg.com>
Message-ID: <14091.52785.260083.448113@amarok.cnri.reston.va.us>

M.-A. Lemburg writes:
>As for the SIG's web-pages: I think there should be a complete
>rewrite of the SIG's status page. 

	OK; I've radically cut down the status page; the information
on it should all be taken into account by the topic guide, anyway.
Version 2.0a15 of the spec has been added to the topic guide as well.
Comments and further suggestions are welcome.  (I still have to add
Andy Dustman's new MySQL module, but have a bus to catch at the
moment -- do that tomorrow.)

	Can anyone draw up a list of the major changes between 1.0 and
2.0, and also send an announcement to c.l.py.announce?

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
Alas, despite wing implants, feathers and wax, and carnal associations with
swans, we will never grow wings. Alas, any true flight we make will always be
externally assisted. Alas, the best we can do is fall and believe ourselves
flying.
    -- Peter Greenaway, _Flying Out of This World_ (1994)



From mal@lemburg.com  Wed Apr  7 23:58:15 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Apr 1999 00:58:15 +0200
Subject: [DB-SIG] Updating the SIG pages
References: <370BBFAC.32658844@lemburg.com> <14091.52785.260083.448113@amarok.cnri.reston.va.us>
Message-ID: <370BE307.1CD69255@lemburg.com>

Andrew M. Kuchling wrote:
> 
> M.-A. Lemburg writes:
> >As for the SIG's web-pages: I think there should be a complete
> >rewrite of the SIG's status page.
> 
>         OK; I've radically cut down the status page; the information
> on it should all be taken into account by the topic guide, anyway.
> Version 2.0a15 of the spec has been added to the topic guide as well.
> Comments and further suggestions are welcome.  (I still have to add
> Andy Dustman's new MySQL module, but have a bus to catch at the
> moment -- do that tomorrow.)

Looks good. Thanks.

>         Can anyone draw up a list of the major changes between 1.0 and
> 2.0,

That's one of the things I want to add as additional section
before announcing it.

> and also send an announcement to c.l.py.announce?

I'll do that next Monday... I think we still need a little time
to get things just right ;-)

-- 
Marc-Andre Lemburg                               Y2000: 268 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From mal@lemburg.com  Thu Apr  8 09:14:23 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Apr 1999 10:14:23 +0200
Subject: [DB-SIG] Updating the SIG pages
References: <Pine.LNX.4.10.9904071709450.10447-100000@kenny.comstar.net>
Message-ID: <370C655F.722EFE36@lemburg.com>

Andy Dustman wrote:
> 
> On Wed, 7 Apr 1999, M.-A. Lemburg wrote:
> 
> > BTW: Even if the SIG is meant for relational databases, wouldn't
> > it be a good idea to open it up for OODBs too ? What about an
> > OODB API (with a DB API compliant adaptor) as new target of
> > discussion ?!
> 
> It sounds like this may be the domain of the DO-SIG (distributed object),
> which is working on CORBA bindings and such. That doesn't mean we can't
> butt in, however. :) Does look interesting...

Well, I was thinking more in terms of e.g. defining a Python
binding for ODMG's OODB model (see http://www.odmg.org). Would
be nice to have searchable pickles of Python objects. Unfortunately,
they only seem to make the standard documentation available in
book form.

Since the OQL looks a lot like SQL, maybe even Gadfly could support
it... or we could use it's nice parsing features to map OQL onto
SQL and then use any of the existing relational DBs as backend.

-- 
Marc-Andre Lemburg                               Y2000: 267 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From mal@lemburg.com  Thu Apr  8 09:43:58 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Apr 1999 10:43:58 +0200
Subject: [DB-SIG] Updating the SIG pages
References: <370BBFAC.32658844@lemburg.com> <14091.52785.260083.448113@amarok.cnri.reston.va.us> <370BE307.1CD69255@lemburg.com>
Message-ID: <370C6C4E.3BB7905E@lemburg.com>

M.-A. Lemburg wrote:
> 
> Andrew M. Kuchling wrote:
> >
> > M.-A. Lemburg writes:
> > >As for the SIG's web-pages: I think there should be a complete
> > >rewrite of the SIG's status page.
> >
> >         OK; I've radically cut down the status page; the information
> > on it should all be taken into account by the topic guide, anyway.
> > Version 2.0a15 of the spec has been added to the topic guide as well.
> > Comments and further suggestions are welcome.  (I still have to add
> > Andy Dustman's new MySQL module, but have a bus to catch at the
> > moment -- do that tomorrow.)
> 
> Looks good. Thanks.

BTW: It would also be nice if there were a link to the original
HTML code of the spec, since package writers might want to
include it in their documentation (sort of like a "printable
version of this page" thing).

Ah yes, and we wanted to include the final 2.0 version somewhere
in the Python standard docs. Would that be possible ?
Even though the standard lib does not include a DB API compatible
package, I think it would produce a little more awareness of
the specification and Python's database connectivity in general.

-- 
Marc-Andre Lemburg                               Y2000: 267 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From adustman@comstar.net  Thu Apr  8 09:48:33 1999
From: adustman@comstar.net (Andy Dustman)
Date: Thu, 8 Apr 1999 04:48:33 -0400 (EDT)
Subject: [DB-SIG] Updating the SIG pages
In-Reply-To: <370C655F.722EFE36@lemburg.com>
Message-ID: <Pine.LNX.4.10.9904080447080.10447-100000@kenny.comstar.net>

On Thu, 8 Apr 1999, M.-A. Lemburg wrote:

> Well, I was thinking more in terms of e.g. defining a Python
> binding for ODMG's OODB model (see http://www.odmg.org). Would

Oh boy, another standards group! I guess http://www.omg.org wasn't
enough... (Been researching CORBA stuff all night, argh) 

-- 
andy dustman  | programmer/analyst |  comstar communications corporation
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d



From akuchlin@cnri.reston.va.us  Sun Apr 11 18:22:33 1999
From: akuchlin@cnri.reston.va.us (A.M. Kuchling)
Date: Sun, 11 Apr 1999 13:22:33 -0400
Subject: [DB-SIG] Change of DB-SIG ownership
Message-ID: <199904111722.NAA01113@207-172-44-186.s186.tnt3.brd.va.dialup.rcn.com>

Michael McLay, the current owner of the Database SIG, is very busy
with other things these days, and no longer has much time to spend on
managing the mailing list and Web page.  Therefore, Michael is happy
to give up ownership of the SIG, and I'll be taking over the
management of the mailing list and DB-SIG Web pages.

   Thanks to Michael for his efforts in getting this SIG started, and
in running it for so long.

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
Time, place, and action may with pains be wrought, / But Genius must be born;
and can never be taught.
    -- John Congreve


From mal@lemburg.com  Mon Apr 12 10:47:17 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 12 Apr 1999 11:47:17 +0200
Subject: [DB-SIG] About to release DB API 2.0...
Message-ID: <3711C125.163C385F@lemburg.com>

Hi everybody,

DB API 2.0 is ready for take-off.

I've done some additional minor editing of the text, spell
corrected it and also clarified one tiny issue I found:
connection.close() and cursor.close() should cause subsequent
actions on the objects to result in an Error exception (or subclass),
not just any kind of exception. [Hope this is OK with everybody...:]

The final version is available from:

	http://starship.skyport.net/~lemburg/DatabaseAPI-2.0.html

I will post an announcement to the main list and c.l.py.announce
later today.

Thanks to everybody who contributed to the new version. I think
the long discussions were well worthwhile and very helpful.

Cheers,
-- 
Marc-Andre Lemburg                               Y2000: 263 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From mal@lemburg.com  Wed Apr 14 09:16:51 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Apr 1999 10:16:51 +0200
Subject: [DB-SIG] DB API 2.0... what about NULLs ?
Message-ID: <37144EF3.7856CDE6@lemburg.com>

I just realized that there is no mention of what to do about
SQL NULL values on the Python side of things.

Maybe we can sneak that definition into 2.0 before Andrew updates
the SIGs web-page...

Most interface modules already do the "right thing" w/r to NULL:
they simply use None as Python equivalent. This means we could add
a sentence:

	  SQL NULL values are represented by the Python
	  None singleton on input and output.

and/or add an aliase NULL for None that the module has to define.

Any ideas ?

-- 
Marc-Andre Lemburg                               Y2000: 261 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From davidcuny@yahoo.fr  Wed Apr 14 14:42:51 1999
From: davidcuny@yahoo.fr (David Cuny)
Date: Wed, 14 Apr 1999 06:42:51 -0700 (PDT)
Subject: [DB-SIG] questions...
Message-ID: <19990414134251.13038.rocketmail@web703.mail.yahoo.com>

Hello,

I'd like to realize an Intranet application with a database. My OS is
NT, my server is APache and my database is DB2.
To use Python through CGI and access data in the database, need I
something special? mxODBC??? and ODBC??? 
I hesitated between python perl and php. Wgat are the advantages to
use Python in my case?
Thanks answering me.

David Cuny
_________________________________________________________
ĘTES-VOUS YAHOO!?
Votre e-mail @yahoo.fr gratuit sur http://courrier.yahoo.fr



From adustman@comstar.net  Wed Apr 14 18:24:02 1999
From: adustman@comstar.net (Andy Dustman)
Date: Wed, 14 Apr 1999 13:24:02 -0400 (EDT)
Subject: [DB-SIG] DB API 2.0... what about NULLs ?
In-Reply-To: <37144EF3.7856CDE6@lemburg.com>
Message-ID: <Pine.LNX.4.10.9904141308560.11777-100000@kenny.comstar.net>

On Wed, 14 Apr 1999, M.-A. Lemburg wrote:

> 	  SQL NULL values are represented by the Python
> 	  None singleton on input and output.

This is no problem.

> and/or add an aliase NULL for None that the module has to define.

You know, I might actually do something like this in MySQLdb. On reading
from the database, NULLs are returned as Py_None (None). On writing to the
databse, a NULL value has to be specified as the token NULL. Part of what
I did to pull this off involves defining a string in the _mysql module
(the C level), i.e. NULL='NULL'. From an application perspective, however,
this None to NULL translation happens transparently (is performed by the
Python level); the application reads and writes None to reprsent a NULL
value.

From an interface perspective, however, I think we should require the
above behavior you propose inserting. It is the de facto standard way of
doing things, and I think we just overlooked it's abscense, since NULL
<--> None is such a natural mapping. NULL should probably not be part of
the specification, since if it is, someone will become dependent on it and
most interfaces won't have it.

-- 
andy dustman  | programmer/analyst |  comstar communications corporation
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d



From mal@lemburg.com  Wed Apr 14 14:48:49 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Apr 1999 15:48:49 +0200
Subject: [DB-SIG] DB API 2.0... what about NULLs ?
References: <37144EF3.7856CDE6@lemburg.com>
Message-ID: <37149CC1.2DD8C7E3@lemburg.com>

M.-A. Lemburg wrote:
> 
> I just realized that there is no mention of what to do about
> SQL NULL values on the Python side of things.
> 
> Maybe we can sneak that definition into 2.0 before Andrew updates
> the SIGs web-page...
> 
> Most interface modules already do the "right thing" w/r to NULL:
> they simply use None as Python equivalent. This means we could add
> a sentence:
> 
>           SQL NULL values are represented by the Python
>           None singleton on input and output.
> 
> and/or add an aliase NULL for None that the module has to define.
> 

Here is the text I'd like to add to the Type Objects section:

"""
NULL 
     SQL NULL values are represented by the Python None singleton
     on input and output. NULL is an alias for None that the module must
     define if the database supports NULL values. 
"""

This has the added advantage of being able to check for NULL
support via hasattr(), e.g. Gadfly should not define it.

If nobody objects, I'll update the spec on starship later today.

-- 
Marc-Andre Lemburg                               Y2000: 261 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From mal@lemburg.com  Wed Apr 14 19:35:14 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Apr 1999 20:35:14 +0200
Subject: [DB-SIG] questions...
References: <19990414134251.13038.rocketmail@web703.mail.yahoo.com>
Message-ID: <3714DFE2.916F33E@lemburg.com>

David Cuny wrote:
> 
> Hello,
> 
> I'd like to realize an Intranet application with a database. My OS is
> NT, my server is APache and my database is DB2.
> To use Python through CGI and access data in the database, need I
> something special? mxODBC??? and ODBC???

Use the win32 odbc module, Sam Rushing's calldll ODBC wrapper or
mxODBC. They all have their pros and cons, but I won't comment
since I'm biased ;-)

> I hesitated between python perl and php. Wgat are the advantages to
> use Python in my case?

There's a pretty well written language comparison on www.python.org
somewhere. I'm doing lot's of CGI stuff: my current project has reached
somewhere around 30k lines of Python code... and it's still easy to
manage.

-- 
Marc-Andre Lemburg                               Y2000: 261 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From adustman@comstar.net  Wed Apr 14 20:06:29 1999
From: adustman@comstar.net (Andy Dustman)
Date: Wed, 14 Apr 1999 15:06:29 -0400 (EDT)
Subject: [DB-SIG] DB API 2.0... what about NULLs ?
In-Reply-To: <37149CC1.2DD8C7E3@lemburg.com>
Message-ID: <Pine.LNX.4.10.9904141500100.11777-100000@kenny.comstar.net>

On Wed, 14 Apr 1999, M.-A. Lemburg wrote:

> Here is the text I'd like to add to the Type Objects section:
> 
> """
> NULL 
>      SQL NULL values are represented by the Python None singleton
>      on input and output. NULL is an alias for None that the module must
>      define if the database supports NULL values. 
> """
> 
> This has the added advantage of being able to check for NULL
> support via hasattr(), e.g. Gadfly should not define it.
> 
> If nobody objects, I'll update the spec on starship later today.

I'll object, for reasons stated earlier: The interface should require None
to be the Python equivalent of NULL. Having more that one way to specify
NULL values which may or be not be present in a given interface seems to
be a good way to create portability problems. This is an even more serious
problem than having connect() parameters being interface-dependent (though
that one is unavoidable and can be fixed in one place in an application
generally). Plus, MySQLdb would run afoul of it, since it defines NULL =
'NULL', but if an application were to see it and make use of it, it would
be writing the string literal 'NULL' instead of the token NULL. (Actually,
I could be NULL = None in my Python layer, but I really think this is a
bad idea.)

Drop the "NULL is an alias for None" bit and I'm happy.

-- 
andy dustman  | programmer/analyst |  comstar communications corporation
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d



From mal@lemburg.com  Wed Apr 14 20:22:20 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 14 Apr 1999 21:22:20 +0200
Subject: [DB-SIG] DB API 2.0... what about NULLs ?
References: <Pine.LNX.4.10.9904141500100.11777-100000@kenny.comstar.net>
Message-ID: <3714EAEC.55C35EE3@lemburg.com>

Andy Dustman wrote:
> 
> On Wed, 14 Apr 1999, M.-A. Lemburg wrote:
> 
> > Here is the text I'd like to add to the Type Objects section:
> >
> > """
> > NULL
> >      SQL NULL values are represented by the Python None singleton
> >      on input and output. NULL is an alias for None that the module must
> >      define if the database supports NULL values.
> > """
> >
> > This has the added advantage of being able to check for NULL
> > support via hasattr(), e.g. Gadfly should not define it.
> >
> > If nobody objects, I'll update the spec on starship later today.
> 
> I'll object, for reasons stated earlier: The interface should require None
> to be the Python equivalent of NULL. Having more that one way to specify
> NULL values which may or be not be present in a given interface seems to
> be a good way to create portability problems. This is an even more serious
> problem than having connect() parameters being interface-dependent (though
> that one is unavoidable and can be fixed in one place in an application
> generally). Plus, MySQLdb would run afoul of it, since it defines NULL =
> 'NULL', but if an application were to see it and make use of it, it would
> be writing the string literal 'NULL' instead of the token NULL. (Actually,
> I could be NULL = None in my Python layer, but I really think this is a
> bad idea.)
> 
> Drop the "NULL is an alias for None" bit and I'm happy.

Ok. I'll just add a note then.

-- 
Marc-Andre Lemburg                               Y2000: 261 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From gstein@lyra.org  Wed Apr 14 23:00:37 1999
From: gstein@lyra.org (Greg Stein)
Date: Wed, 14 Apr 1999 15:00:37 -0700
Subject: [DB-SIG] DB API 2.0... what about NULLs ?
References: <Pine.LNX.4.10.9904141500100.11777-100000@kenny.comstar.net>
Message-ID: <37151005.6AA6D2FE@lyra.org>

Andy Dustman wrote:
> 
> On Wed, 14 Apr 1999, M.-A. Lemburg wrote:
> ...
> > If nobody objects, I'll update the spec on starship later today.
>...
> Drop the "NULL is an alias for None" bit and I'm happy.

I object, too, for the same reasons stated by Andy. It doesn't really
make sense to have an alias for None.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/


From mal@lemburg.com  Thu Apr 15 08:05:20 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 15 Apr 1999 09:05:20 +0200
Subject: [DB-SIG] DB API 2.0... what about NULLs ?
References: <Pine.LNX.4.10.9904141500100.11777-100000@kenny.comstar.net> <37151005.6AA6D2FE@lyra.org>
Message-ID: <37158FB0.1FFC3F82@lemburg.com>

Greg Stein wrote:
> 
> Andy Dustman wrote:
> >
> > On Wed, 14 Apr 1999, M.-A. Lemburg wrote:
> > ...
> > > If nobody objects, I'll update the spec on starship later today.
> >...
> > Drop the "NULL is an alias for None" bit and I'm happy.
> 
> I object, too, for the same reasons stated by Andy. It doesn't really
> make sense to have an alias for None.

The updated version is on my Python Pages. It only contains a
mention of using None as NULL. The alias part is gone. BTW,
the idea was not to actually use the alias in execute()s, but
to be able to test whether the database knows about NULLs.

-- 
Marc-Andre Lemburg                               Y2000: 260 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From akuchlin@cnri.reston.va.us  Thu Apr 15 16:25:00 1999
From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling)
Date: Thu, 15 Apr 1999 11:25:00 -0400 (EDT)
Subject: [DB-SIG] Three MySQL modules?
Message-ID: <199904151525.LAA00843@amarok.cnri.reston.va.us>

I haven't yet added Andy Dustman's MySQLdb module to the database
topic guide.  Can someone clarify the situation with the three MySQL
modules?  There's James Henstridge's mySQLmodule; the copy on
python.org is dated 09-Oct-1997, so it's probably unmaintained.  
There's Joerg Senekowitsch's MySQLmodule, dated 28-Dec-1998, so it's
probably still maintained, and there's Andy Dustman's module,
announced earlier this module.

	Which ones should be listed in the topic guide?  I think it's
OK to drop the Henstridge one; does the Dustman code supersede the
Senekowitsch module?  Authors, can you clarify this?

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
But if enough of us dream, if a bare thousand of us dream, we can change the
world. We can dream it anew! A world in which no cat suffers from the malice
of humans. In which no cats are killed by human caprice. A world that we rule.
    -- The visionary cat, in SANDMAN #18: "A Dream of a Thousand Cats"



From adustman@comstar.net  Thu Apr 15 18:19:15 1999
From: adustman@comstar.net (Andy Dustman)
Date: Thu, 15 Apr 1999 13:19:15 -0400 (EDT)
Subject: [DB-SIG] DB API 2.0... what about NULLs ?
In-Reply-To: <37158FB0.1FFC3F82@lemburg.com>
Message-ID: <Pine.LNX.4.10.9904151309470.11020-100000@kenny.comstar.net>

On Thu, 15 Apr 1999, M.-A. Lemburg wrote:

> The updated version is on my Python Pages. It only contains a
> mention of using None as NULL. The alias part is gone. BTW,
> the idea was not to actually use the alias in execute()s, but
> to be able to test whether the database knows about NULLs.

Oh, well that's another matter. On one hand, the cursor description will
tell you what columns are nullable. On the other, this doesn't necessarily
tell you if the database allows NULL columns. I see three immediate
possibilities:

1) a module attribute nullable which is true if the database supports the
concept of a NULL column.

2) Require the interface to translate None into the appropriate
false-equivalent data values, i.e. None to '', 0, 0.0, 0L as appropriate,
upon writing to the database. No translation would be required on reading.

3) Both of these.

Whether or not we should try to slide it into the 2.0 spec is another
matter; a little late, perhaps, to be thinking of this, and may fixing
something that ain't broke. At least on databases which support NULL
columns, the worst that would have to be done is to add nullable = 1. For
those not supporting NULL (I suspect virtually all SQL databases support
it), it might be difficult to know in advance what the correct data type
should be for writing.

-- 
andy dustman  | programmer/analyst |  comstar communications corporation
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d



From gstein@lyra.org  Thu Apr 15 19:56:27 1999
From: gstein@lyra.org (Greg Stein)
Date: Thu, 15 Apr 1999 11:56:27 -0700
Subject: [DB-SIG] DB API 2.0... what about NULLs ?
References: <Pine.LNX.4.10.9904151309470.11020-100000@kenny.comstar.net>
Message-ID: <3716365B.3816C39C@lyra.org>

Andy Dustman wrote:
>...
> Whether or not we should try to slide it into the 2.0 spec is another
> matter; a little late, perhaps, to be thinking of this, and may fixing
> something that ain't broke. At least on databases which support NULL

It seems like a non-problem and 2.0 is out the door...

Why is this issue a problem? What is going on?

At a minimum, 2.0 is done with. Any changes go into the next rev. (IMO,
of course :-)

-g

--
Greg Stein, http://www.lyra.org/


From adustman@comstar.net  Thu Apr 15 20:41:25 1999
From: adustman@comstar.net (Andy Dustman)
Date: Thu, 15 Apr 1999 15:41:25 -0400 (EDT)
Subject: [DB-SIG] Three MySQL modules?
In-Reply-To: <199904151525.LAA00843@amarok.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.9904151515030.28169-100000@kenny.comstar.net>

On Thu, 15 Apr 1999, Andrew M. Kuchling wrote:

> I haven't yet added Andy Dustman's MySQLdb module to the database
> topic guide.  Can someone clarify the situation with the three MySQL
> modules?  There's James Henstridge's mySQLmodule; the copy on
> python.org is dated 09-Oct-1997, so it's probably unmaintained.  
> There's Joerg Senekowitsch's MySQLmodule, dated 28-Dec-1998, so it's
> probably still maintained, and there's Andy Dustman's module,
> announced earlier this module.
> 
> 	Which ones should be listed in the topic guide?  I think it's
> OK to drop the Henstridge one; does the Dustman code supersede the
> Senekowitsch module?  Authors, can you clarify this?

I was in contact with Joerg Senekowitsch late last year because of
problems I noticed in MySQLmodule-1.4, i.e. no use of
Py_BEGIN_ALLOW_THREADS ... Py_END_ALLOW_THREADS. He asked if I wanted to
take over maintanence. :) He said he there was going to be a 1.5 version,
but I got tired of waiting around for it. Also, the code was real ugly
because it was designed to work originally like a perl DBI module (yuck).
It also had a Python wrapper, written by James Henstridge.

The README in MySQLmodule-1.4 says:

MySQLmodule-1.x is based on mySQLmodule-0.1.4 by

   Copyright (C) 1997  Joseph Skinner <joe@earthlink.co.nz>
   Copyright (C) 1997  James Henstridge <james@daa.com.au>

   mySQLmodule-0.1.4 is based on mSQLmodule, which is

   Portions copyright (C) 1995  Thawte Consulting, cc
   Portions copyright (C) 1994  Anthony Baxter.

See 'Credits' for details.

Joerg Senekowitsch (senekow@ibm.net), October 1998

Confused yet? To top it off, the mSQLmodule author (I think it was Baxter)
wrote me to thank me for writing a new module and putting a bullet in the
old code; he was tired getting questions about it, even though he hadn't
maintained it for years.

My MySQLdb is only designed to work with MySQL-3.22.19+. I know for a fact
that it doesn't presently compile with 3.22.11, because of some new
constants which have since been added. I don't expect it to work with 3.21
at all. However, MySQLmodule-1.4 should work with 3.21, so it may yet have
some life to it, though use of MySQL-3.21 is discouraged nowadays, I
think.

Also, MySQLdb is completely new, and shares no code with any earlier
interface, and it's 100% free software (others might be as well). OTOH,
it's not widely tested yet, but compatible with the 2.0 DB API. They are
not 100% compatible, either. If you use MySQLmodule's Mysqldb:

>>> import Mysqldb
>>> conn = Mysqldb.mysqldb('mysql@localhost root rootpasswd')
>>> curs = conn.cursor()
>>> curs.execute("insert into user (host, user) values ('%s', '%s')",
... [('localhost', 'linus'), ('somewhere.com.au', 'james')])

Equivalent code for MySQLdb (my module) is:

>>> import MySQLdb
>>> conn = MySQLdb.connect(user="root", passwd="rootpasswd")
>>> curs = conn.cursor()
>>> curs.execute("insert into user (host, user) values (%s, %s)",
... [('localhost', 'linus'), ('somewhere.com.au', 'james')])

Note the differences in the query strings. So MySQLdb is definitely not a
drop-in replacement, but definitely better for new apps, particularly if
threading is desired.

So to answer your question, probably both mine and Senekowitsch's ought to
be listed: Mine for MySQL-3.22.19+, and Senekowitsch's for MySQL-3.21.30
(according to the README).

-- 
andy dustman  | programmer/analyst |  comstar communications corporation
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d



From akuchlin@cnri.reston.va.us  Thu Apr 15 20:57:52 1999
From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling)
Date: Thu, 15 Apr 1999 15:57:52 -0400 (EDT)
Subject: [DB-SIG] Three MySQL modules?
In-Reply-To: <Pine.LNX.4.10.9904151515030.28169-100000@kenny.comstar.net>
References: <199904151525.LAA00843@amarok.cnri.reston.va.us>
 <Pine.LNX.4.10.9904151515030.28169-100000@kenny.comstar.net>
Message-ID: <14102.17537.575437.723488@amarok.cnri.reston.va.us>

Andy Dustman writes:
>So to answer your question, probably both mine and Senekowitsch's ought to
>be listed: Mine for MySQL-3.22.19+, and Senekowitsch's for MySQL-3.21.30
>(according to the README).

	Done; I've dropped the Henstridge module completely from the
topic guide, though it'll still be available in the contrib directory.

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I am falling / Like a stone / Being born again / Into the sweet morning fog.
    -- Kate Bush, "The Morning Fog"




From mal@lemburg.com  Thu Apr 15 23:40:40 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 16 Apr 1999 00:40:40 +0200
Subject: [DB-SIG] DB API 2.0... what about NULLs ?
References: <Pine.LNX.4.10.9904151309470.11020-100000@kenny.comstar.net> <3716365B.3816C39C@lyra.org>
Message-ID: <37166AE8.1FAE25C@lemburg.com>

Greg Stein wrote:
> 
> Andy Dustman wrote:
> >...
> > Whether or not we should try to slide it into the 2.0 spec is another
> > matter; a little late, perhaps, to be thinking of this, and may fixing
> > something that ain't broke. At least on databases which support NULL
> 
> It seems like a non-problem and 2.0 is out the door...
> 
> Why is this issue a problem? What is going on?
> 
> At a minimum, 2.0 is done with. Any changes go into the next rev. (IMO,
> of course :-)

Right, we'll keep it in mind for 2.1.

I really didn't mean to stir up anything; I was just a little
surprised that we forgot the NULLs in all those discussions about
.nextset()s and return values ;-)

The note I added to the end of the spec merely points out the
already used fact that None should be used as NULL on input 
and output. Nothing more.

For now, the main objective is getting some 2.0 compliant
modules out there. AFAIK, only Andy's module is 2.0 compliant.
I'm working hard on mxODBC... stumbling over all kinds of
inconsistencies in the way ODBC is implemented by the various
drivers along the way :-/

-- 
Marc-Andre Lemburg                               Y2000: 260 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From adustman@comstar.net  Fri Apr 16 04:17:52 1999
From: adustman@comstar.net (Andy Dustman)
Date: Thu, 15 Apr 1999 23:17:52 -0400 (EDT)
Subject: [DB-SIG] Three MySQL modules?
In-Reply-To: <14102.17537.575437.723488@amarok.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.9904152316550.28238-100000@kenny.comstar.net>

On Thu, 15 Apr 1999, Andrew M. Kuchling wrote:

> Andy Dustman writes:
> >So to answer your question, probably both mine and Senekowitsch's ought to
> >be listed: Mine for MySQL-3.22.19+, and Senekowitsch's for MySQL-3.21.30
> >(according to the README).
> 
> 	Done; I've dropped the Henstridge module completely from the
> topic guide, though it'll still be available in the contrib directory.

Another compatibility note: MySQLdb requires Python 1.5.2. Details of why
are in the docs on the web page. 

-- 
andy dustman  | programmer/analyst |  comstar communications corporation
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d



From deirdre@deirdre.net  Thu Apr 22 03:52:06 1999
From: deirdre@deirdre.net (Deirdre Saoirse)
Date: Wed, 21 Apr 1999 22:52:06 -0400 (EDT)
Subject: [DB-SIG] Informix on IRIX?
Message-ID: <Pine.LNX.3.96.990421224802.10107C-100000@localhost.deirdre.org>

I'm using Python on IRIX (among other platforms) and have not been able to
successfully make the "Informix" module. I'm going to try Kinfxdb. Has
anyone made either of these under IRIX?

_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
"At a risk of being called sexist, ageist and French, if you put 
multimedia, a leather skirt and lipstick on a grandmother and take her 
to a night club, she's still not going to get lucky." -- Jean Louis 
Gassee (of Be) on Windows 2000 being "multimedia."



From deirdre@deirdre.net  Thu Apr 22 22:52:57 1999
From: deirdre@deirdre.net (Deirdre Saoirse)
Date: Thu, 22 Apr 1999 17:52:57 -0400 (EDT)
Subject: [DB-SIG] Informix on IRIX?
In-Reply-To: <Pine.LNX.3.96.990421224802.10107C-100000@localhost.deirdre.org>
Message-ID: <Pine.LNX.3.96.990422175219.11370B-100000@localhost.deirdre.org>

More to the point, I've gotten it to:

esql -e kinfxdb.ec
/www/informix/bin/esql[351]: /usr/informix/lib/esql/esqlc:  not found
make: *** [kinfxdb.c] Error 127

...however, esql isn't a directory!

On Wed, 21 Apr 1999, Deirdre Saoirse wrote:

> I'm using Python on IRIX (among other platforms) and have not been able to
> successfully make the "Informix" module. I'm going to try Kinfxdb. Has
> anyone made either of these under IRIX?
> 
> _Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
> "At a risk of being called sexist, ageist and French, if you put 
> multimedia, a leather skirt and lipstick on a grandmother and take her 
> to a night club, she's still not going to get lucky." -- Jean Louis 
> Gassee (of Be) on Windows 2000 being "multimedia."
> 
> 
> _______________________________________________
> DB-SIG maillist  -  DB-SIG@python.org
> http://www.python.org/mailman/listinfo/db-sig
> 

_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
"At a risk of being called sexist, ageist and French, if you put 
multimedia, a leather skirt and lipstick on a grandmother and take her 
to a night club, she's still not going to get lucky." -- Jean Louis 
Gassee (of Be) on Windows 2000 being "multimedia."



From johnm@magnet.com  Thu Apr 22 23:10:43 1999
From: johnm@magnet.com (John Mitchell)
Date: Thu, 22 Apr 1999 18:10:43 -0400
Subject: [DB-SIG] Informix on IRIX?
In-Reply-To: <Pine.LNX.3.96.990422175219.11370B-100000@localhost.deirdre.org>
Message-ID: <Pine.SGI.4.05.9904221805340.4212-100000@lemur.magnet.com>

On Thu, 22 Apr 1999, Deirdre Saoirse wrote:

> More to the point, I've gotten it to:
> 
> esql -e kinfxdb.ec
> /www/informix/bin/esql[351]: /usr/informix/lib/esql/esqlc:  not found
> make: *** [kinfxdb.c] Error 127
> 
> ...however, esql isn't a directory!


Try setting your half-dozen-odd environment variables.  For example, on my
machine:

setenv INFORMIXDIR   /usr/local/informix/

and I have a "esqlc" in /usr/local/informix/lib/esql/esqlc (which the
above is trying to reference), and also /usr/local/informix/demo/esqlc

Take a look at /usr/local/informix/installesql.

My Informix version is:

onstat | head -1

INFORMIX-OnLine Version 7.12.UC1 -- On-Line -- Up 7 days 02:47:27 -- 29520
Kbytes


hope this helps.


- j




From Deirdre Saoirse <deirdre@deirdre.net>  Thu Apr 22 23:34:12 1999
From: Deirdre Saoirse <deirdre@deirdre.net> (Deirdre Saoirse)
Date: Thu, 22 Apr 1999 18:34:12 -0400 (EDT)
Subject: [DB-SIG] Informix on IRIX?
In-Reply-To: <Pine.SGI.4.05.9904221805340.4212-100000@lemur.magnet.com>
Message-ID: <Pine.LNX.3.96.990422182222.11432C-100000@localhost.deirdre.org>

On Thu, 22 Apr 1999, John Mitchell wrote:

> Try setting your half-dozen-odd environment variables.  For example, on my
> machine:
> 
> setenv INFORMIXDIR   /usr/local/informix/

In my case, it's /www/informix (and no, it's not something I can change).

However, note that it was looking for /usr/informix.... which doesn't
exist! I can't find anywhere where that was set.


> and I have a "esqlc" in /usr/local/informix/lib/esql/esqlc (which the
> above is trying to reference), and also /usr/local/informix/demo/esqlc

> Take a look at /usr/local/informix/installesql.
> 
> My Informix version is:
> 
> onstat | head -1
> 
> INFORMIX-OnLine Version 7.12.UC1 -- On-Line -- Up 7 days 02:47:27 -- 29520
> Kbytes
> 
> 
> hope this helps.

Not sure what about the last part is relevant....

_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
"At a risk of being called sexist, ageist and French, if you put 
multimedia, a leather skirt and lipstick on a grandmother and take her 
to a night club, she's still not going to get lucky." -- Jean Louis 
Gassee (of Be) on Windows 2000 being "multimedia."




From Deirdre Saoirse <deirdre@deirdre.net>  Thu Apr 22 23:47:58 1999
From: Deirdre Saoirse <deirdre@deirdre.net> (Deirdre Saoirse)
Date: Thu, 22 Apr 1999 18:47:58 -0400 (EDT)
Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX?
In-Reply-To: <Pine.SGI.4.05.9904221805340.4212-100000@lemur.magnet.com>
Message-ID: <Pine.LNX.3.96.990422184343.11432F-100000@localhost.deirdre.org>

I had the bright-bulb idea of building it as the informix user...

> ./bld.sh 
Platform:  IRIX64
Shared lib suffix: 
Python include dir:  /usr/local/include/python1.5
Python config dir:  /usr/local/lib/python1.5/config
Informix libraries:  -lixsql -lixasf -lixgen -lixos -lixgls -lm

        gcc -c -O -fpic kinfxdb.c -I/usr/local/include/python1.5
-I/usr/local/lib/python1.5/config -I/www/informix/incl/esql
"-DPLATFORM=IRIX64"
In file included from /usr/local/include/python1.5/Python.h:49,
                 from kinfxdb.ec:7:
/usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.7.2.2/include/stdio.h:43:
warning: empty declaration
as: Warning: /kinfxdb.c, line 1: label should be inside .ent/.end block:
gcc2_compiled.
     gcc2_compiled.:
as: Warning: /kinfxdb.c, line 1: label should be inside .ent/.end block:
__gnu_compiled_c
     __gnu_compiled_c:
as: Error: /kinfxdb.c, line 1: stmt extends past logical end
      .globl initdbi .text
as: Error: /kinfxdb.c, line 1: stmt extends past logical end
      .globl PyDict_SetItemString .text
as: Error: /kinfxdb.c, line 1: stmt extends past logical end
      .globl PyLong_FromLong .text
as: Error: /kinfxdb.c, line 1: stmt extends past logical end
      .globl PyModule_GetDict .text
as: Error: /kinfxdb.c, line 1: stmt extends past logical end
      .globl Py_InitModule4 .text
as: Error: /kinfxdb.c, line 1: stmt extends past logical end
      .globl _iqcftch .text
as: Error: /kinfxdb.c, line 1: stmt extends past logical end
      .globl intofmtasc .text
as: Error: /kinfxdb.c, line 1: stmt extends past logical end
      .globl rjulmdy .text
as: Error: /kinfxdb.c, line 1: stmt extends past logical end
      .globl mktime .text
as: Error: /kinfxdb.c, line 1: stmt extends past logical end
      .globl dbiMakeDate .text
[snip]

as: Error: /kinfxdb.c, line 1: stmt extends past logical end
      .globl _iqsetconnect .text
*** Error code 1 (bu21)
> gcc --version
2.7.2.2

Given that the statement on line 1 doesn't...it must be the 

#include <slqhdr.h> it's barfing at...right?

_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
"At a risk of being called sexist, ageist and French, if you put 
multimedia, a leather skirt and lipstick on a grandmother and take her 
to a night club, she's still not going to get lucky." -- Jean Louis 
Gassee (of Be) on Windows 2000 being "multimedia."




From mal@lemburg.com  Fri Apr 23 10:35:47 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 23 Apr 1999 11:35:47 +0200
Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX?
References: <Pine.LNX.3.96.990422184343.11432F-100000@localhost.deirdre.org>
Message-ID: <37203EF3.4D648781@lemburg.com>

Deirdre Saoirse wrote:
> 
> I had the bright-bulb idea of building it as the informix user...
> 
> > ./bld.sh
> Platform:  IRIX64
> Shared lib suffix:
> Python include dir:  /usr/local/include/python1.5
> Python config dir:  /usr/local/lib/python1.5/config
> Informix libraries:  -lixsql -lixasf -lixgen -lixos -lixgls -lm
> 
>         gcc -c -O -fpic kinfxdb.c -I/usr/local/include/python1.5
> -I/usr/local/lib/python1.5/config -I/www/informix/incl/esql
> "-DPLATFORM=IRIX64"
> In file included from /usr/local/include/python1.5/Python.h:49,
>                  from kinfxdb.ec:7:
> /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.7.2.2/include/stdio.h:43:
> warning: empty declaration
> as: Warning: /kinfxdb.c, line 1: label should be inside .ent/.end block:
> gcc2_compiled.
>      gcc2_compiled.:
> as: Warning: /kinfxdb.c, line 1: label should be inside .ent/.end block:
> __gnu_compiled_c
>      __gnu_compiled_c:
> as: Error: /kinfxdb.c, line 1: stmt extends past logical end
>       .globl initdbi .text
> [snip]
> 
> as: Error: /kinfxdb.c, line 1: stmt extends past logical end
>       .globl _iqsetconnect .text
> *** Error code 1 (bu21)
> > gcc --version
> 2.7.2.2

Note that you should normally *never* get error messages from the
assembler when compiling a C program. It seems you've got a
configuration problem in your compiler setup. I would presume
that gcc works best with gas as assembler, yet the dump indicates
that it is in fact using some OS supplied assembler.

-- 
Marc-Andre Lemburg                               Y2000: 252 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------




From harri.pasanen@trema.com  Fri Apr 23 12:59:30 1999
From: harri.pasanen@trema.com (Harri Pasanen)
Date: Fri, 23 Apr 1999 13:59:30 +0200
Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX?
References: <Pine.LNX.3.96.990422184343.11432F-100000@localhost.deirdre.org> <37203EF3.4D648781@lemburg.com>
Message-ID: <372060A2.54BEC835@trema.com>

"M.-A. Lemburg" wrote:
> 
> Note that you should normally *never* get error messages from the
> assembler when compiling a C program. It seems you've got a
> configuration problem in your compiler setup. I would presume
> that gcc works best with gas as assembler, yet the dump indicates
> that it is in fact using some OS supplied assembler.
> 

Actually you sometime may get those, as there might be inline assembler
code in system headers. For instance, my egcs on Linux refuses to
compile files using the default FD_ZERO macro, as FD_ZERO apparently
expands to inline assembly code that gcc 2.7.2.3 happily compiles.  In
these cases my workaround has been to define FD_ZERO myself to pure C
code.

On other environments than Linux GCC quite often uses system assembler
and linker, including system supplied headers and libraries.

I don't claim to know what the original posters problem was without
seeing the source code.

Thank God its Friday,

Harri


From mal@lemburg.com  Fri Apr 23 14:13:06 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 23 Apr 1999 15:13:06 +0200
Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX?
References: <Pine.LNX.3.96.990422184343.11432F-100000@localhost.deirdre.org> <37203EF3.4D648781@lemburg.com> <372060A2.54BEC835@trema.com>
Message-ID: <372071E2.5A92CC03@lemburg.com>

Harri Pasanen wrote:
> 
> "M.-A. Lemburg" wrote:
> >
> > Note that you should normally *never* get error messages from the
> > assembler when compiling a C program. It seems you've got a
> > configuration problem in your compiler setup. I would presume
> > that gcc works best with gas as assembler, yet the dump indicates
> > that it is in fact using some OS supplied assembler.
> >
> 
> Actually you sometime may get those, as there might be inline assembler
> code in system headers. For instance, my egcs on Linux refuses to
> compile files using the default FD_ZERO macro, as FD_ZERO apparently
> expands to inline assembly code that gcc 2.7.2.3 happily compiles.  In
> these cases my workaround has been to define FD_ZERO myself to pure C
> code.

Ah, ok, forgot about the inline assembler. I was thinking of
assembler code produced by the compiler. Inline assembler can
of course cause troubles...

> On other environments than Linux GCC quite often uses system assembler
> and linker, including system supplied headers and libraries.

To the original poster:

There is an Informix SDK available for free which includes
ODBC drivers. Don't know if they provide IRIX binaries, but that
would enable you to connect to Informix using mxODBC.

-- 
Marc-Andre Lemburg                               Y2000: 252 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From johnm@magnet.com  Fri Apr 23 15:38:21 1999
From: johnm@magnet.com (John Mitchell)
Date: Fri, 23 Apr 1999 10:38:21 -0400
Subject: [DB-SIG] Re: Getting warmer! Re: [DB-SIG] Informix on IRIX?
In-Reply-To: <Pine.LNX.3.96.990422184343.11432F-100000@localhost.deirdre.org>
Message-ID: <Pine.SGI.4.05.9904231035350.4212-100000@lemur.magnet.com>

On Thu, 22 Apr 1999, Deirdre Saoirse wrote:

> I had the bright-bulb idea of building it as the informix user...
>
> [with gcc, lots of assembler errors appear]


On my machine, you cant really use gcc -- SGI's C compiler is pretty good,
use that one.  If you cant, then as someone said, dork with the
configuration.

I have two SGIs with 'cc' and 'gcc' on each.  Compiling a short program on
each of the four variations gives me FOUR different results!  Me find big
stick now...


got a linux box somewhere?  :)

- j





From deirdre@deirdre.net  Fri Apr 23 18:49:19 1999
From: deirdre@deirdre.net (Deirdre Saoirse)
Date: Fri, 23 Apr 1999 13:49:19 -0400 (EDT)
Subject: [DB-SIG] Re: Getting warmer! Re: [DB-SIG] Informix on IRIX?
In-Reply-To: <Pine.SGI.4.05.9904231035350.4212-100000@lemur.magnet.com>
Message-ID: <Pine.LNX.3.96.990423134812.12350B-100000@localhost.deirdre.org>

On Fri, 23 Apr 1999, John Mitchell wrote:

> I have two SGIs with 'cc' and 'gcc' on each.  Compiling a short program on
> each of the four variations gives me FOUR different results!  Me find big
> stick now...

Ah.

> got a linux box somewhere?  :)

The problem was that this was going on a production server and I have no
choice about that being Linux or SGI. It's SGI. ::sigh::

I don't know much about them (duh!) but it's a "learning experience."

_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
"At a risk of being called sexist, ageist and French, if you put 
multimedia, a leather skirt and lipstick on a grandmother and take her 
to a night club, she's still not going to get lucky." -- Jean Louis 
Gassee (of Be) on Windows 2000 being "multimedia."



From deirdre@deirdre.net  Fri Apr 23 19:06:54 1999
From: deirdre@deirdre.net (Deirdre Saoirse)
Date: Fri, 23 Apr 1999 14:06:54 -0400 (EDT)
Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX?
In-Reply-To: <372060A2.54BEC835@trema.com>
Message-ID: <Pine.LNX.3.96.990423135305.12350E-100000@localhost.deirdre.org>

On Fri, 23 Apr 1999, Harri Pasanen wrote:

> I don't claim to know what the original posters problem was without
> seeing the source code.

It appears, on further investigation, that the gcc was for IRIX 5.3 (if 
the pathname had anything to do with version) and we're apparently running
6.4:

>uname -a
IRIX64 coyote 6.4 02121744 IP27

But the source code came right off the python site..it was the informix
hooks that started with a k.

_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
"At a risk of being called sexist, ageist and French, if you put 
multimedia, a leather skirt and lipstick on a grandmother and take her 
to a night club, she's still not going to get lucky." -- Jean Louis 
Gassee (of Be) on Windows 2000 being "multimedia."



From deirdre@deirdre.net  Fri Apr 23 19:19:14 1999
From: deirdre@deirdre.net (Deirdre Saoirse)
Date: Fri, 23 Apr 1999 14:19:14 -0400 (EDT)
Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX?
In-Reply-To: <372071E2.5A92CC03@lemburg.com>
Message-ID: <Pine.LNX.3.96.990423141609.12350I-100000@localhost.deirdre.org>

On Fri, 23 Apr 1999, M.-A. Lemburg wrote:

> To the original poster:
> 
> There is an Informix SDK available for free which includes
> ODBC drivers. Don't know if they provide IRIX binaries, but that
> would enable you to connect to Informix using mxODBC.

This is a possibility -- thanks for the suggestion. I'll see if we have a
support contract with Informix...if so, I'll give them a ring today.

I have bigger, hairier problems this morning -- we just launched a web
site live that has a new Informix back end...it mails the programmers
whenever there's an error and something went wrong with the setup. We were
up VERY late last night and I see I have a few thousand more emails this
morning. ::sniff::

_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
"At a risk of being called sexist, ageist and French, if you put 
multimedia, a leather skirt and lipstick on a grandmother and take her 
to a night club, she's still not going to get lucky." -- Jean Louis 
Gassee (of Be) on Windows 2000 being "multimedia."



From mal@lemburg.com  Fri Apr 23 19:48:20 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 23 Apr 1999 20:48:20 +0200
Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX?
References: <Pine.LNX.3.96.990423141609.12350I-100000@localhost.deirdre.org>
Message-ID: <3720C074.2F31470C@lemburg.com>

Deirdre Saoirse wrote:
> 
> On Fri, 23 Apr 1999, M.-A. Lemburg wrote:
> 
> > To the original poster:
> >
> > There is an Informix SDK available for free which includes
> > ODBC drivers. Don't know if they provide IRIX binaries, but that
> > would enable you to connect to Informix using mxODBC.
> 
> This is a possibility -- thanks for the suggestion. I'll see if we have a
> support contract with Informix...if so, I'll give them a ring today.

Here is the link to the SDK:

	http://www.intranet.com
 
> I have bigger, hairier problems this morning -- we just launched a web
> site live that has a new Informix back end...it mails the programmers
> whenever there's an error and something went wrong with the setup. We were
> up VERY late last night and I see I have a few thousand more emails this
> morning. ::sniff::

A log file is probably a better idea... but I guess you know by now
;-)

Cheers,
-- 
Marc-Andre Lemburg                               Y2000: 252 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------



From deirdre@deirdre.net  Fri Apr 23 19:51:13 1999
From: deirdre@deirdre.net (Deirdre Saoirse)
Date: Fri, 23 Apr 1999 14:51:13 -0400 (EDT)
Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX?
In-Reply-To: <3720C074.2F31470C@lemburg.com>
Message-ID: <Pine.LNX.3.96.990423145015.12350O-100000@localhost.deirdre.org>

On Fri, 23 Apr 1999, M.-A. Lemburg wrote:

> > I have bigger, hairier problems this morning -- we just launched a web
> > site live that has a new Informix back end...it mails the programmers
> > whenever there's an error and something went wrong with the setup. We were
> > up VERY late last night and I see I have a few thousand more emails this
> > morning. ::sniff::
> 
> A log file is probably a better idea... but I guess you know by now
> ;-)

Actually, I'm glad we did it this way. We knew *immediately*.

Besides, for those files we write to, we've been getting emails about
locking errors....

_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
"At a risk of being called sexist, ageist and French, if you put 
multimedia, a leather skirt and lipstick on a grandmother and take her 
to a night club, she's still not going to get lucky." -- Jean Louis 
Gassee (of Be) on Windows 2000 being "multimedia."



From deirdre@deirdre.net  Fri Apr 23 21:31:56 1999
From: deirdre@deirdre.net (Deirdre Saoirse)
Date: Fri, 23 Apr 1999 16:31:56 -0400 (EDT)
Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX?
In-Reply-To: <372071E2.5A92CC03@lemburg.com>
Message-ID: <Pine.LNX.3.96.990423162709.12921C-100000@localhost.deirdre.org>

On Fri, 23 Apr 1999, M.-A. Lemburg wrote:

> > Actually you sometime may get those, as there might be inline assembler
> > code in system headers. For instance, my egcs on Linux refuses to
> > compile files using the default FD_ZERO macro, as FD_ZERO apparently
> > expands to inline assembly code that gcc 2.7.2.3 happily compiles.  In
> > these cases my workaround has been to define FD_ZERO myself to pure C
> > code.
> 
> Ah, ok, forgot about the inline assembler. I was thinking of
> assembler code produced by the compiler. Inline assembler can
> of course cause troubles...

I switched, per suggestions, from gcc to cc and attempted to recompile.

I *know* the fatal error I'm getting now is IRIX related....

ld32: FATAL 12: Expecting n32 objects: /www/informix/lib/esql/libixsql.so
is o32.

What I don't understand is what it means.

As far as all the warnings, I tend to think they're less critical....

_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
"At a risk of being called sexist, ageist and French, if you put 
multimedia, a leather skirt and lipstick on a grandmother and take her 
to a night club, she's still not going to get lucky." -- Jean Louis 
Gassee (of Be) on Windows 2000 being "multimedia."



From johnm@magnet.com  Fri Apr 23 21:54:28 1999
From: johnm@magnet.com (John Mitchell)
Date: Fri, 23 Apr 1999 16:54:28 -0400
Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX?
In-Reply-To: <Pine.LNX.3.96.990423162709.12921C-100000@localhost.deirdre.org>
Message-ID: <Pine.SGI.4.05.9904231649050.4212-100000@lemur.magnet.com>

On Fri, 23 Apr 1999, Deirdre Saoirse wrote:

> I switched, per suggestions, from gcc to cc and attempted to recompile.
> 
> I *know* the fatal error I'm getting now is IRIX related....
> 
> ld32: FATAL 12: Expecting n32 objects: /www/informix/lib/esql/libixsql.so
> is o32.
> 
> What I don't understand is what it means.


argh!  Irix switched from "old-style" o32 objects to "new-style" n32, and
all your libraries have to match or you're hosed.

Since you cant recompile the Informix library above, do a "make clean",
then recompile after telling your C compiler to generate "old-style"
object files.

Hmm.  I just found my informix-libary Makefile:

	LDFLAGS=-shared -all -o32

Try that.  Maybe zap the "-shared".  If you want, I can post the rest of
the makefile for your perusal.


- j




From deirdre@deirdre.net  Fri Apr 23 22:08:01 1999
From: deirdre@deirdre.net (Deirdre Saoirse)
Date: Fri, 23 Apr 1999 17:08:01 -0400 (EDT)
Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX?
In-Reply-To: <Pine.SGI.4.05.9904231649050.4212-100000@lemur.magnet.com>
Message-ID: <Pine.LNX.3.96.990423165657.12921H-100000@localhost.deirdre.org>

On Fri, 23 Apr 1999, John Mitchell wrote:

> argh!  Irix switched from "old-style" o32 objects to "new-style" n32, and
> all your libraries have to match or you're hosed.

Ah! This explains the acronym. :)

> Since you cant recompile the Informix library above, do a "make clean",
> then recompile after telling your C compiler to generate "old-style"
> object files.
> 
> Hmm.  I just found my informix-libary Makefile:
> 
> 	LDFLAGS=-shared -all -o32
> 
> Try that.  Maybe zap the "-shared".  If you want, I can post the rest of
> the makefile for your perusal.

I'd love the makefile...I intend to make the necessary changes to the
script after I manage to get it to compile and send them off to the
maintainer. :)

_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
"At a risk of being called sexist, ageist and French, if you put 
multimedia, a leather skirt and lipstick on a grandmother and take her 
to a night club, she's still not going to get lucky." -- Jean Louis 
Gassee (of Be) on Windows 2000 being "multimedia."



From johnm@magnet.com  Fri Apr 23 22:20:05 1999
From: johnm@magnet.com (John Mitchell)
Date: Fri, 23 Apr 1999 17:20:05 -0400
Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX?
In-Reply-To: <Pine.LNX.3.96.990423165657.12921H-100000@localhost.deirdre.org>
Message-ID: <Pine.SGI.4.05.9904231713550.4212-200000@lemur.magnet.com>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---792678398-1306080360-924902405=:4212
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 23 Apr 1999, Deirdre Saoirse wrote:

> I'd love the makefile...I intend to make the necessary changes to the
> script after I manage to get it to compile and send them off to the
> maintainer. :)

There's nothing magic -- I just took the original Makefile and tweaked a
line or three.  Enclosed.


- j


---792678398-1306080360-924902405=:4212
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=Makefile
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SGI.4.05.9904231720050.4212@lemur.magnet.com>
Content-Description: 
Content-Disposition: attachment; filename=Makefile

Iz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PQ0KIyBNYWtlZmlsZQ0KIyAkSWQ6IE1ha2VmaWxl
LHYgMS40IDE5OTcvMDIvMTkgMTU6MTc6MTYgYmVydGlsIEV4cCBiZXJ0aWwg
JCANCiMNCiM9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT0NCiMgTWFraW5nIEFuIC5zbyBNb2R1
bGUNCiMgVGhlIHNpbXBsZXN0IHdheSB0byBnZW5lcmF0ZSBhbiBpbmZvcm1p
eCBtb2R1bGUgaXMgdG8ganVzdCBydW4gdGhpcw0KIyBNYWtlZmlsZSByaWdo
dCBvZiB3aXRoIGVudmlyb25tZW50IHZhcmlhYmxlDQojCUlORk9STUlYRElS
DQojIGFuZCBNYWtlZmlsZSB2YXJpYWJsZQ0KIwlQWUlOQ0wNCiMgc2V0IHBy
b3Blci4NCiMgSU5GT1JNSVhESVIgaXMgdXN1YWxseSBzZXQgdG8gJy91c3Iv
aW5mb3JtaXgnLg0KIyBUaGVuIGNvcHkgdGhlIHJlc3VsdGluZyBpbmZvcm1p
eGRiLnNvIHdoZXJldmVyIGFuZCBzZXQgUFlUSE9OUEFUSC4NCiMNCiM9PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PQ0KIyBOZXZlciBtaW5kIHRoZXNlIHR3bw0KIy1EREFURUZJ
WCANCiMgTllJOiAtRERBVEVUSU1FRklYDQojPT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiMg
Rm9yIFNvbGFyaXMgMi41DQojDQojQ0M9Z2NjICQoREJHRkxHKSAtRFNURVAx
IC1ERVhURU5ERURfRVJST1JfSEFORExJTkcNCkNDPWNjICQoREJHRkxHKSAt
RFNURVAxIC1ERVhURU5ERURfRVJST1JfSEFORExJTkcgLW8zMlwNCg0KI0lO
Rk9STUlYRElSCT0gL3Vzci9sb2NhbC9pbmZvcm1peA0KTEQ9bGQNCkNQPWNw
DQojTERGTEFHUz0tRw0KTERGTEFHUz0tc2hhcmVkIC1hbGwgLW8zMg0KREJH
RkxHPS1nDQpMRFNVRkY9LnNvDQpMSUJESVJTPSAtTCR7SU5GT1JNSVhESVJ9
L2xpYi9lc3FsIC1MJHtJTkZPUk1JWERJUn0vbGliDQoNCiM9PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PQ0KIyBGb3IgSFAtVVggMTAuMDENCiMNCiMtIENDPWM4OSAkKERCR0ZM
RykgLURTVEVQMSANCiMtIExEPWxkDQojLSBDUD1jcA0KIy0gTERGTEFHUz0t
YiAtRQ0KIy0gQ0ZMQUdTPSt6DQojLSBEQkdGTEc9LWcNCiMtIExEU1VGRj0u
c2wNCiMtIExJQkRJUlM9IC1MJHtJTkZPUk1JWERJUn0vbGliIC1MJHtJTkZP
Uk1JWERJUn0vbGliL2VzcWwNCg0KI1BZSU5DTD0vdXNyL2xvY2FsL2luY2x1
ZGUvcHl0aG9uMS41DQpQWUlOQ0w9L21hZ25ldC91c2Vycy9kYXZlbS9zcmMv
UHl0aG9uLTEuNS4xDQoNCiNJTkNMVURFUz0tSSR7SU5GT1JNSVhESVJ9L2lu
Y2wvZXNxbCAtSSQoUFlJTkNMKQ0KSU5DTFVERVM9LUkke0lORk9STUlYRElS
fS9pbmNsL2VzcWwgLUkkKFBZSU5DTCkgLUkkKFBZSU5DTCkvSW5jbHVkZQ0K
TElCUz0tbGFzZiAtbHNxbCAtbG9zIC1sZ2VuDQoNCkZJTEVTRVQgPSBNYWtl
ZmlsZSBSRUFETUUgaWZ4ZGJtb2R1bGUuZWMgZGJpLmMgZGJpLmggaW5mb3Jt
aXhkYi5weSBcDQoJICBfaW5mb3JtaXhkYi5tYWsgX2luZm9ybWl4ZGIuZGVm
DQoNCmFsbDogX2luZm9ybWl4ZGIkKExEU1VGRikNCg0KaWZ4ZGJtb2R1bGUu
YzogaWZ4ZGJtb2R1bGUuZWMNCgkkJHtJTkZPUk1JWERJUn0vYmluL2VzcWwg
LWUgJDwNCg0KaWZ4ZGJtb2R1bGUubzogaWZ4ZGJtb2R1bGUuYyBkYmkuaA0K
CSQoQ0MpICQoQ0ZMQUdTKSAtYyAkPCAkKElOQ0xVREVTKQ0KDQpfaW5mb3Jt
aXhkYiQoTERTVUZGKTogaWZ4ZGJtb2R1bGUubyBkYmkubw0KCSQoTEQpICQo
TERGTEFHUykgLW8gJEAgJDwgJChMSUJESVJTKSAkKExJQlMpIGRiaS5vICQo
TElCUykgJChMSUJTKQ0KCWNobW9kIDc1NSAkQA0KDQpkYmkubzogZGJpLmMg
ZGJpLmgNCgkkKENDKSAkKENGTEFHUykgLWMgJDwgJChJTkNMVURFUykNCg0K
ZGlzdDoNCgl0YXIgY2YgaW5mb3JtaXhkYi50YXIgJChGSUxFU0VUKQ0KCWd6
aXAgaW5mb3JtaXhkYi50YXINCg0KY2xlYW46DQoJcm0gLXJmICokKExEU1VG
RikgKi5vIGlmeGRibW9kdWxlLmMNCg==
---792678398-1306080360-924902405=:4212--


From deirdre@deirdre.net  Fri Apr 23 22:37:13 1999
From: deirdre@deirdre.net (Deirdre Saoirse)
Date: Fri, 23 Apr 1999 17:37:13 -0400 (EDT)
Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX?
In-Reply-To: <Pine.SGI.4.05.9904231713550.4212-200000@lemur.magnet.com>
Message-ID: <Pine.LNX.3.96.990423173510.12921O-100000@localhost.deirdre.org>

On Fri, 23 Apr 1999, John Mitchell wrote:

Thanks mucho. :)

I just looked at your email address. Boy don't I feel like an idiot. :)

(working out of the west coast office of the same company....)

_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
"At a risk of being called sexist, ageist and French, if you put 
multimedia, a leather skirt and lipstick on a grandmother and take her 
to a night club, she's still not going to get lucky." -- Jean Louis 
Gassee (of Be) on Windows 2000 being "multimedia."



From deirdre@deirdre.net  Fri Apr 23 23:19:15 1999
From: deirdre@deirdre.net (Deirdre Saoirse)
Date: Fri, 23 Apr 1999 18:19:15 -0400 (EDT)
Subject: [DB-SIG] Yay and thanks....
In-Reply-To: <Pine.SGI.4.05.9904231649050.4212-100000@lemur.magnet.com>
Message-ID: <Pine.LNX.3.96.990423181632.13310D-100000@localhost.deirdre.org>

Well thanks to John's help, I got it to compile. :)

Now I just have to test it...
:)

_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
"At a risk of being called sexist, ageist and French, if you put 
multimedia, a leather skirt and lipstick on a grandmother and take her 
to a night club, she's still not going to get lucky." -- Jean Louis 
Gassee (of Be) on Windows 2000 being "multimedia."



From Deirdre Saoirse <deirdre@deirdre.net>  Mon Apr 26 00:20:10 1999
From: Deirdre Saoirse <deirdre@deirdre.net> (Deirdre Saoirse)
Date: Sun, 25 Apr 1999 19:20:10 -0400 (EDT)
Subject: [DB-SIG] Next Question (eval version of SOLID)
In-Reply-To: <Pine.LNX.3.96.990422184343.11432F-100000@localhost.deirdre.org>
Message-ID: <Pine.LNX.3.96.990422222848.11985D-100000@localhost.deirdre.org>

Has anyone built SolidPython (or any hooks for SOLID) for the *evaluation*
version? I don't really need a heavier weight database for this particular
implementation, so this would probably be the best.

$ make
cc -Wunused -fPIC -g -I/usr/include/python1.5
-I/home/deeny/solidSDK30/Linux_glibc2/include -I.   -c soliddb.c -o
soliddb.o
soliddb.c:33: cli0core.h: No such file or directory
soliddb.c:34: cli0ext1.h: No such file or directory
make: *** [soliddb.o] Error 1

...are the errors and indeed these files are not included:

$ cd include
$ ls
cli0cli.h   cli0defs.h  cli0env.h


_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
"At a risk of being called sexist, ageist and French, if you put 
multimedia, a leather skirt and lipstick on a grandmother and take her 
to a night club, she's still not going to get lucky." -- Jean Louis 
Gassee (of Be) on Windows 2000 being "multimedia."





From adustman@comstar.net  Mon Apr 26 02:18:02 1999
From: adustman@comstar.net (Andy Dustman)
Date: Sun, 25 Apr 1999 21:18:02 -0400 (EDT)
Subject: [DB-SIG] Next Question (eval version of SOLID)
In-Reply-To: <Pine.LNX.3.96.990422222848.11985D-100000@localhost.deirdre.org>
Message-ID: <Pine.LNX.4.10.9904252117250.13023-100000@kenny.comstar.net>

On Sun, 25 Apr 1999, Deirdre Saoirse wrote:

> Has anyone built SolidPython (or any hooks for SOLID) for the *evaluation*
> version? I don't really need a heavier weight database for this particular
> implementation, so this would probably be the best.

SolidPython is horrible. Don't use it. mxODBC works well for Solid.

-- 
andy dustman  | programmer/analyst |  comstar communications corporation
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d



From kuppler@vnet.net  Mon Apr 26 05:08:31 1999
From: kuppler@vnet.net (kuppler@vnet.net)
Date: Mon, 26 Apr 1999 04:08:31
Subject: [DB-SIG] AD:Family Reunion T Shirts & More
Message-ID: <199904261153.HAA15541@python.org>

Message sent by:  Kuppler Graphics, 32 West Main Street, Maple Shade, New Jersey, 08052,
1-800-810-4330.   This list will NOT be sold.  All addresses 
are automatically added to our remove list.

Hello.  My name is Bill from Kuppler Graphics.  We do screenprinting on T Shirts, Sweatshirts,
Jackets, Hats, Tote Bags and more!

Do you or someone you know have a Family Reunion coming up?  Kuppler Graphics would like to
provide you with some great looking T Shirts for your Reunion.

Kuppler Graphics can also provide you with custom T's and promotional items such as imprinted
magnets, keychains, pens, mugs, hats, etc. for your business or any fundraising activity
(church, school, business etc.) We also can provide you with quality embroidery. 

We are a family owned company with over 15 years of experience.  

All work is done at this location.  No middle man.  Our prices are great!

Click reply to email us or call 1-800-810-4330 for more info


Bill
Kuppler Graphics
 
 
 
 
 
 
 
 
 
 
 


From deirdre@deirdre.net  Fri Apr 30 21:08:12 1999
From: deirdre@deirdre.net (Deirdre Saoirse)
Date: Fri, 30 Apr 1999 16:08:12 -0400 (EDT)
Subject: [DB-SIG] Informixdb hooks: questions again
In-Reply-To: <Pine.SGI.4.05.9904231649050.4212-100000@lemur.magnet.com>
Message-ID: <Pine.LNX.3.96.990430160654.9527E-100000@localhost.deirdre.org>

OK, now that I think we have everything set up...theres NO docs..

What do I pass in the informixdb.informixdb statement? Would it be the
same order as in Javascript? ('INFORMIX', hostname, username, password,
database)?

_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
"Solving today's problems tomorrow, with yesterday's technology."



From johnm@magnet.com  Fri Apr 30 22:04:30 1999
From: johnm@magnet.com (John Mitchell)
Date: Fri, 30 Apr 1999 17:04:30 -0400
Subject: [DB-SIG] Re: Informixdb hooks: questions again
In-Reply-To: <Pine.LNX.3.96.990430160654.9527E-100000@localhost.deirdre.org>
Message-ID: <Pine.SGI.4.05.9904301654240.4212-200000@lemur.magnet.com>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---792678398-313455780-925506270=:4212
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 30 Apr 1999, Deirdre Saoirse wrote:

> OK, now that I think we have everything set up...theres NO docs..

docs?  you mean, besides the code?  :)

> What do I pass in the informixdb.informixdb statement? Would it be the
> same order as in Javascript? ('INFORMIX', hostname, username, password,
> database)?

Check out enclosed file, which I use as the lowest-level Python object.  
Following this paragraph is the next higher stuff, which deals with
stage-vs-live setup issues.

SQL reminds me of "Worse is Better" by Richard Gabriel at
http://www.jwz.org/worse-is-better.html 

- j


# to test db connection:
#
# python -c 'import ad_db  ; db=ad_db.open() ; 
#   db.execute('select * from sponsor_slot') ; print db.fetchall()
#

# $Id: ad_db.py,v 1.2 1998/09/15 15:20:06 johnm Exp $


import mysite				# plays with sys.path
import sys
import informixdb, os

debug = 0

_informix_vars = [

# host-specific parameters:
#
    (['maroon','lingua'],	None,		    (
        "adserver@ifmx_maroon", "dbuser", 'dbpass')),
    (['maroon','lingua'],	'INFORMIXDIR',      '/www/informix'),
    (['maroon','lingua'],	'INFORMIXSQLHOSTS', '/www/informix/etc/sqlhosts.ifmx'),
    (['maroon','lingua'],	'INFORMIXSERVER',   'ifmx_maroon'), # shared-mem

    (['peach'],	None,		    (
        "ads@ifmx_peach_shm", "dbuserdb", 'dbpass')),
    (['peach'],	'INFORMIXDIR',      '/www/informix'),
    (['peach'],	'INFORMIXSQLHOSTS', '/www/informix/etc/sqlhosts.ifmx'),
    (['peach'],	'INFORMIXSERVER',   'ifmx_peach_shm'), # shared-mem
#    (['peach'],	'INFORMIXSERVER',   'ifmx_peach'),# normal

    (['violet'], None,               (
        "ads@ifmx_violet", "dbuserdb", 'dbpass')),
    (['violet'], 'INFORMIXDIR',      '/www/informix'),
    (['violet'], 'INFORMIXSQLHOSTS', '/www/informix/etc/sqlhosts.ifmx'),
    (['violet'], 'INFORMIXSERVER',   'ifmx_violet'), # shared-mem
#    (['violet'],        'INFORMIXSERVER',   'ifmx_violet'),# normal

# generic defaults (must be last):
#
     (None,	None,		    (
	 "ads@ifmx_dingdong", "magdev", 'dbpass')),
    (None,	'INFORMIXSERVER',   'ifmx_tsunami'),
    (None,	'INFORMIXDIR',      '/usr/local/informix'),
    (None,	'INFORMIXSQLHOSTS', '/usr/local/informix/etc/sqlhosts.ifmx'),
    (None,	'INFORMIXTERM',     'terminfo'),

]

global _informix_login			# XX ugh!
_informix_login = None


# X: global '_informix_login' modified
#
def setup(myHostname):
    # set any missing Informix environment variables.
    # Ack!
    #
    env = os.environ
    global _informix_login
    _informix_login	= None

    for hostlist, k,v in _informix_vars:
	if not hostlist or myHostname in hostlist:

	    # set login information
	    #
	    if not k:
		if not _informix_login:
		    _informix_login = v
		continue

	    # set environment info
	    # (allow shell's environment to override us):
	    #
	    if not env.has_key(k):
		if debug: sys.stderr.write("set: %s\t%s\n" % (k,v))
		env[k] = v
	    else:
		if debug: sys.stderr.write("env: %s\t%s\n" % (k,v))


# X: global '_informix_login' used
#
def open(hostname=None):

    if not hostname:
	import socket
	hostname = socket.gethostname()

    setup(hostname)				# XX: sigh

    db = None

    if _informix_login:		
	db = apply(informixdb.informixdb, _informix_login)
    else:
	raise KeyError, "%s: host not recognized" % hostname

    return db


def test(hostname=None):
    db = open(hostname)
    db.execute('select * from dummy')	# XX assumes this table exists!
    print db.fetchall()



if __name__=="__main__":
    print test()


---792678398-313455780-925506270=:4212
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="informixdb.py"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SGI.4.05.9904301704300.4212@lemur.magnet.com>
Content-Description: informixdb.py
Content-Disposition: attachment; filename="informixdb.py"

IyAkSWQ6IGluZm9ybWl4ZGIucHksdiAxLjEuMS4xIDE5OTgvMDgvMzEgMjE6
MzY6MTkgbWF5byBFeHAgJA0KIyBpbmZvcm1peGRiLnB5DQojDQojIFRoaXMg
aXMgYSB0cml2aWFsIHB5dGhvbiB3cmFwcGVyIGFyb3VuZCB0aGUgQyBjb3Jl
IF9pbmZvcm1peGRiLnNvDQojDQojIEFjY29yZGluZyB0byB0aGUgREJBUEkg
c3BlYywgYSBjb25uZWN0aW9uIG9iamVjdCBpcyBleHBlY3RlZCB0byBzdXBw
bHkNCiMgdGhlIHNhbWUgc2V0IG9mIGZ1bmN0aW9ucyBhcyBkbyBhIGN1cnNv
ciBvYmplY3QuIFRoaXMgaXMgZml4ZWQgaGVyZSBieQ0KIyBhbiBpbXBsaWNp
dCBjdXJzb3IuDQojDQojIE5ZRCA9IE5vdCBZZXQgRGVmaW5lZCBieSBEQkFQ
SQ0KIyBOWUkgPSBOb3QgWWV0IEltcGxlbWVudGVkDQojDQp0cnk6DQogICAg
aW1wb3J0IF9pbmZvcm1peGRiDQpleGNlcHQgSW1wb3J0RXJyb3IsIG1zZzoN
CiAgICByYWlzZSBJbXBvcnRFcnJvciwgKCJDYW5ub3QgbG9hZCBDIGNvcmUg
bW9kdWxlIGZvciAiDQoJCQkiaW5mb3JtaXggZGIgaW50ZXJmYWNlOlxuXHQl
cyIgJSBtc2cpDQoNCg0KY2xhc3MgaW5mb3JtaXhkYjoNCiAgICBkZWYgX19p
bml0X18oc2VsZiwgbG9nb24sIHVzZXIsIHBhc3N3b3JkKToNCglzZWxmLmNv
bm4gPSBfaW5mb3JtaXhkYi5pbmZvcm1peGRiKGxvZ29uLCB1c2VyLCBwYXNz
d29yZCkNCglzZWxmLl9jdXJzb3IgPSBzZWxmLmNvbm4uY3Vyc29yKCkNCglz
ZWxmLl9sYXN0X3NxbCA9IE5vbmUNCg0KICAgIGRlZiBfX2dldGF0dHJfXyhz
ZWxmLCBhdHRyKToNCglpZiBhdHRyID09ICdkZXNjcmlwdGlvbic6DQoJICAg
IHJldHVybiBzZWxmLl9jdXJzb3IuZGVzY3JpcHRpb24NCgllbGlmIGF0dHIg
PT0gJ2FycmF5c2l6ZSc6DQoJICAgIHJldHVybiBzZWxmLl9jdXJzb3IuYXJy
YXlzaXplDQoJZWxpZiBhdHRyID09ICdlcnJvcic6DQoJICAgIHJldHVybiBf
aW5mb3JtaXhkYi5lcnJvcg0KCWVsaWYgYXR0ciA9PSAnc3FsJzoNCgkgICAg
cmV0dXJuIHNlbGYuX2xhc3Rfc3FsDQoJZWxzZToNCgkgICAgcmFpc2UgQXR0
cmlidXRlRXJyb3IsIGF0dHINCg0KICAgIGRlZiBpc1ZhbGlkKHNlbGYpOg0K
CXNlbGYuZXhlY3V0ZSgnc2VsZWN0IGNvdW50KCopIGZyb20gc3lzdGFibGVz
JykNCglzZWxmLmZldGNoYWxsKCkNCglyZXR1cm4gMQ0KDQogICAgZGVmIGNv
bW1pdChzZWxmKToNCglzZWxmLmNvbm4uY29tbWl0KCkNCg0KICAgIGRlZiBy
b2xsYmFjayhzZWxmKToNCglzZWxmLmNvbm4ucm9sbGJhY2soKQ0KDQogICAg
ZGVmIGN1cnNvcihzZWxmKToNCglyZXR1cm4gc2VsZi5jb25uLmN1cnNvcigp
DQoNCiAgICBkZWYgY2FsbHByb2Moc2VsZiwgcGFyYW1zID0gTm9uZSk6DQoJ
cGFzcyAjIE5ZRA0KDQogICAgZGVmIGV4ZWN1dGUoc2VsZiwgKmFyZ3MpOg0K
CXNlbGYuX2xhc3Rfc3FsID0gYXJncw0KCWFwcGx5KHNlbGYuX2N1cnNvci5l
eGVjdXRlLCBhcmdzKQ0KDQogICAgZGVmIGZldGNob25lKHNlbGYpOg0KCXJl
dHVybiBzZWxmLl9jdXJzb3IuZmV0Y2hvbmUoKQ0KDQogICAgZGVmIGZldGNo
bWFueShzZWxmLCBzaXplID0gTm9uZSk6DQoJcmV0dXJuIHNlbGYuX2N1cnNv
ci5mZXRjaG1hbnkoc2l6ZSkNCg0KICAgIGRlZiBmZXRjaGFsbChzZWxmKToN
CglyZXR1cm4gc2VsZi5fY3Vyc29yLmZldGNoYWxsKCkNCg0KICAgIGRlZiBj
bG9zZShzZWxmKToNCglzZWxmLl9jdXJzb3IuY2xvc2UoKQ0KCXNlbGYuY29u
bi5jbG9zZSgpDQoJc2VsZi5fY3Vyc29yID0gTm9uZQ0KCXNlbGYuY29ubiA9
IE5vbmUNCg0KICAgIGRlZiBzZXRpbnB1dHNpemVzKHNlbGYsIHNpemVzKToN
CglwYXNzICMgTllEDQoNCiAgICBkZWYgc2V0b3V0cHV0c2l6ZXMoc2VsZiwg
c2l6ZXMsIGNvbCA9IE5vbmUpOg0KCXBhc3MgIyBOWUQNCg0KICAgIGRlZiB1
bmxvYWQoc2VsZiwgZmlsZSwgc3FsLCBzZXBlcmF0b3I9Tm9uZSk6DQogICAg
ICAgIGltcG9ydCBzdHJpbmcNCiAgICAgICAgDQogICAgICAgIGJhdGNoc2l6
ZQk9IDIwDQogICAgICAgIHNlcGVyYXRvcgk9IHNlcGVyYXRvciBvciAnfCcN
CiAgICAgICAgb3V0cHV0CQk9IG9wZW4oZmlsZSwgJ3cnKQ0KDQogICAgICAg
IGMJCT0gc2VsZi5jdXJzb3IoKQ0KICAgICAgICBjLmV4ZWN1dGUoc3FsKQ0K
ICAgICAgICB3aGlsZSAxOg0KICAgICAgICAgICAgYmF0Y2hkYXRhCT0gYy5m
ZXRjaG1hbnkoYmF0Y2gpDQogICAgICAgICAgICBpZiBub3QgYmF0Y2hkYXRh
Og0KICAgICAgICAgICAgICAgIGJyZWFrDQogICAgICAgICAgICBmb3Igcm93
IGluIGJhdGNoZGF0YToNCiAgICAgICAgICAgICAgICBvdXRwdXQud3JpdGUo
IHN0cmluZy5qb2luKHJvdywgc2VwZXJhdG9yKSApDQogICAgICAgICAgICAg
ICAgb3V0cHV0LndyaXRlKCAnXG4nICkNCiAgICAgICAgb3V0cHV0LmNsb3Nl
KCkNCiAgICAgICAgYy5jbG9zZSgpDQogICAgICAgIA0K
---792678398-313455780-925506270=:4212--