From raymondkelly@prodigy.net  Thu Mar  2 03:12:34 2000
From: raymondkelly@prodigy.net (raymondkelly)
Date: Wed, 01 Mar 2000 19:12:34 -0800
Subject: [DB-SIG] Help with informixdb
Message-ID: <38BDDC22.62686C37@prodigy.net>

Hi,

I have installed and built the informixdb module on HPUX 10.2 and I am
having some trouble relating the examples on the use of the module to
version 1.0 of the API. I have been using a GADFLY database to prove out
some concepts and I need to connect to a informix database.

I would greatly appreciate it, if someone could send me a snippet of
code showing a connection to an informix database, a sample SQL
statement would be a bonus. I am assuming that my GADFLY code should
work after I get connected to the informix database.

Thanks

Raymond




From Garrett Gradisar <garrett@rage.x13.com>  Wed Mar  8 18:21:21 2000
From: Garrett Gradisar <garrett@rage.x13.com> (Garrett Gradisar)
Date: Wed, 8 Mar 2000 11:21:21 -0700 (MST)
Subject: [DB-SIG] a little help please
Message-ID: <Pine.LNX.3.96.1000308111053.8510A-100000@rage.x13.com>

#BEGIN CODE
from pg import DB

x = pg.DB('ggroup', None, -1, None, None, 'ggroup', '*******')
#open connection to database ggroup, user ggroup, password deleted to
#protect me.

newq = 'select id,sname,lname,rcolor,weeks,whenw,blocksize,perweek '
newq = newq+'from require'

r = x.query(newq) # Get all data from table require in order

print r # the fields are in order here

print r.dictresult() 
#when I do this the fields are no longer in the currect order

#END CODE

why? what am I doing wrong, my sql query specifies the correct order and
when I print r, it looks fine, but then if i use dictresult() the order changes.

I need them in the correct order so I can print them in an html table.

-Garrett
garrett@x13.com





From adustman@comstar.net  Thu Mar  9 00:03:30 2000
From: adustman@comstar.net (Andy Dustman)
Date: Wed, 8 Mar 2000 19:03:30 -0500 (EST)
Subject: [DB-SIG] [ANNOUNCEMENT] MySQLdb-0.1.3 released
Message-ID: <Pine.LNX.4.10.10003081835580.24156-100000@kenny.comstar.net>

MySQLdb-0.1.3 has been released. You can find it at:

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

Amazingly, MySQLdb-0.1.2 is the most-clicked item in the Vaults of
Parnassus, beating out more interesting things like Numerical Python,
wxWindows, Gadfly, and Zope (I'm touched :):

    http://www.vex.net/parnassus/

What's changed:

- Core dump on exit under certain conditions (probably only when
  using executeXXX() on dictionaries) seems to be fixed.

- cursor.fetchXXXDict() methods added for backwards-compatibility with
  MySQLmodule (plus some people think it's cool to have).

Zope smokers: You _probably_ don't need this upgrade, either; I don't
think the bug ever affected the ZMySQLDA (it was in a function not used by
ZMySQLDA), and the new fetchXXXDict() stuff seems unlikely to be used by
it. Although, it's got me thinking about adding a describe_Zope() method
that returns the items dictionary that gets built up; that might provide a
modest improvement in speed. Let me know if you use this and think you
need more speed; would help most on queries with many columns and few
rows. But, I don't really want to maintain ZMySQLDA, as I don't really
have time to be a hard-core Zope smoker; hopefully Mike P. or someone at
DC will incorporate this as a separate release of ZMySQLDA (maybe v2?)

Thanks to Elliot Lee who originally pointed out the core dump bug, and
Scott Parish who helped me test the fix out.

Author: Andy Dustman <adustman@comstar.net>
License: Python-style

<P><A HREF="http://starship.python.net/crew/adustman/MySQLdb.html">MySQLdb
0.1.3</A> - interface to MySQL-3.22 (08-Mar-2000)

-- 
andy dustman       |     programmer/analyst     |      comstar.net, inc.
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
"Therefore, sweet knights, if you may doubt your strength or courage, 
come no further, for death awaits you all, with nasty, big, pointy teeth!"





From adustman@comstar.net  Thu Mar  9 06:24:23 2000
From: adustman@comstar.net (Andy Dustman)
Date: Thu, 9 Mar 2000 01:24:23 -0500 (EST)
Subject: [DB-SIG] a little help please
In-Reply-To: <Pine.LNX.3.96.1000308111053.8510A-100000@rage.x13.com>
Message-ID: <Pine.LNX.4.10.10003090122140.8642-100000@kenny.comstar.net>

On Wed, 8 Mar 2000, Garrett Gradisar wrote:

> 
> #BEGIN CODE
> from pg import DB
> 
> x = pg.DB('ggroup', None, -1, None, None, 'ggroup', '*******')
> #open connection to database ggroup, user ggroup, password deleted to
> #protect me.
> 
> newq = 'select id,sname,lname,rcolor,weeks,whenw,blocksize,perweek '
> newq = newq+'from require'
> 
> r = x.query(newq) # Get all data from table require in order
> 
> print r # the fields are in order here
> 
> print r.dictresult() 
> #when I do this the fields are no longer in the currect order
> 
> #END CODE
> 
> why? what am I doing wrong, my sql query specifies the correct order and
> when I print r, it looks fine, but then if i use dictresult() the order changes.
> 
> I need them in the correct order so I can print them in an html table.

I would guess this is because r.dictresult() returns results as a
dictionary, which are not ordered. But I know nothing about this pg
module; this is just a guess. 

-- 
andy dustman       |     programmer/analyst     |      comstar.net, inc.
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
"Therefore, sweet knights, if you may doubt your strength or courage, 
come no further, for death awaits you all, with nasty, big, pointy teeth!"



From darcy@druid.net  Thu Mar  9 08:30:47 2000
From: darcy@druid.net (D'Arcy J.M. Cain)
Date: Thu, 9 Mar 2000 03:30:47 -0500 (EST)
Subject: [DB-SIG] a little help please
In-Reply-To: <Pine.LNX.3.96.1000308111053.8510A-100000@rage.x13.com> from Garrett Gradisar at "Mar 8, 2000 11:21:21 am"
Message-ID: <m12SyLH-000AXbC@druid.net>

I assume this is PyGreSQL, right?  Note that this is not DB-SIG compliant
(yet) and probably belongs better on the PyGreSQL mailing list which you
can subscribe to at http://www.vex.net/mailman/listinfo/pygresql/.

Thus spake Garrett Gradisar
> print r # the fields are in order here
> 
> print r.dictresult() 
> #when I do this the fields are no longer in the currect order

That's right.  The dictresult() method returns a list of dictionaries
which are not ordered.  The idea is to use the value like this:

for row in r.dictresult():
  print """Name: %(name)s, Address: %(address)s""" % row

If you want it ordered, use getresult() instead.

> I need them in the correct order so I can print them in an html table.

I do this all the time with dictresult().  See http://www.druid.net/rides/
for a more complete example.  The link at the bottom allows you to view
the Python that generated the page.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.


From mal@lemburg.com  Thu Mar  9 14:49:20 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 09 Mar 2000 15:49:20 +0100
Subject: [DB-SIG] [ANNOUNCEMENT] MySQLdb-0.1.3 released
References: <Pine.LNX.4.10.10003081835580.24156-100000@kenny.comstar.net>
Message-ID: <38C7B9F0.AD100475@lemburg.com>

> What's changed:
> 
> - Core dump on exit under certain conditions (probably only when
>   using executeXXX() on dictionaries) seems to be fixed.
> 
> - cursor.fetchXXXDict() methods added for backwards-compatibility with
>   MySQLmodule (plus some people think it's cool to have).
> 

Could you elaborate a bit ? What do these methods do and
how are dictionaries involved ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From adustman@comstar.net  Thu Mar  9 15:38:48 2000
From: adustman@comstar.net (Andy Dustman)
Date: Thu, 9 Mar 2000 10:38:48 -0500 (EST)
Subject: [DB-SIG] [ANNOUNCEMENT] MySQLdb-0.1.3 released
In-Reply-To: <38C7B9F0.AD100475@lemburg.com>
Message-ID: <Pine.LNX.4.10.10003091022120.19506-100000@kenny.comstar.net>

On Thu, 9 Mar 2000, M.-A. Lemburg wrote:

> > What's changed:
> > 
> > - Core dump on exit under certain conditions (probably only when
> >   using executeXXX() on dictionaries) seems to be fixed.
> > 
> > - cursor.fetchXXXDict() methods added for backwards-compatibility with
> >   MySQLmodule (plus some people think it's cool to have).
> > 
> 
> Could you elaborate a bit ? What do these methods do and
> how are dictionaries involved ?

cursor.fetchrow(), of course, returns the result as a sequence of values,
usually a tuple. cursor.fetchrowDict() returns the result as a dictionary,
where the keys are the column names and the values are the column values.

Joe Skinner, original author of MySQLmodule, has since pointed out to me
that this does not actually provide backwards-compatibility with
MySQLmodule, since MySQLmodule would set the keys to table.column, to
guarantee key uniqueness. In these cases, I would say it is best to modify
the query to use the AS keyword to rename fields, i.e.:

SELECT t1.name AS name1, t2.name AS name2, t1.id FROM t1, t2
WHERE t1.id = t2.id;

(I'm not 100% sure the is the correct syntax, but close enough.)

If that query is executed on cursor, then cursor.fetchone() would return
something like:

('Bob', 'Robert', 1313)

but cursor.fetchoneDict() would return:

{'name1': 'Bob', 'name2': 'Robert', 'id': 1313}

In general, SQL column names are valid Python attribute names (ignoring
things like Python keywords or quoted column names, i.e. "Embedded Sp").
Most SQL implementations (by the standard) do not have case-sensitive
column names, unless the quoting is done, but MySQL is case-sensitive.

Plus, I am working on a Python slapd backend for LDAP, and it would
simplify making a module that acted essentially as a MySQL backend, if
MySQL column names could be directly used as LDAP attributes and vice
versa.

Anyone got any feelings about which is the "right" way to implement this?

-- 
andy dustman       |     programmer/analyst     |      comstar.net, inc.
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
"Therefore, sweet knights, if you may doubt your strength or courage, 
come no further, for death awaits you all, with nasty, big, pointy teeth!"




From mal@lemburg.com  Thu Mar  9 18:04:41 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 09 Mar 2000 19:04:41 +0100
Subject: [DB-SIG] [ANNOUNCEMENT] MySQLdb-0.1.3 released
References: <Pine.LNX.4.10.10003091022120.19506-100000@kenny.comstar.net>
Message-ID: <38C7E7B9.ADD83BFA@lemburg.com>

Andy Dustman wrote:
> 
> On Thu, 9 Mar 2000, M.-A. Lemburg wrote:
> 
> > > What's changed:
> > >
> > > - Core dump on exit under certain conditions (probably only when
> > >   using executeXXX() on dictionaries) seems to be fixed.
> > >
> > > - cursor.fetchXXXDict() methods added for backwards-compatibility with
> > >   MySQLmodule (plus some people think it's cool to have).
> > >
> >
> > Could you elaborate a bit ? What do these methods do and
> > how are dictionaries involved ?
> 
> cursor.fetchrow(), of course, returns the result as a sequence of values,
> usually a tuple. cursor.fetchrowDict() returns the result as a dictionary,
> where the keys are the column names and the values are the column values.

How does this help with columns which are the result of
a SQL function, e.g. select max(value) from table ?

Wouldn't the same functionality be available by simply
merging the information from cursor.description and the
result of .fetchone() (that's how my own abstract DB class works,
BTW) ?
 
> Joe Skinner, original author of MySQLmodule, has since pointed out to me
> that this does not actually provide backwards-compatibility with
> MySQLmodule, since MySQLmodule would set the keys to table.column, to
> guarantee key uniqueness. In these cases, I would say it is best to modify
> the query to use the AS keyword to rename fields, i.e.:
> 
> SELECT t1.name AS name1, t2.name AS name2, t1.id FROM t1, t2
> WHERE t1.id = t2.id;
> 
> (I'm not 100% sure the is the correct syntax, but close enough.)

Should be ok... according to ANSI SQL.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From adustman@comstar.net  Thu Mar  9 19:46:49 2000
From: adustman@comstar.net (Andy Dustman)
Date: Thu, 9 Mar 2000 14:46:49 -0500 (EST)
Subject: [DB-SIG] [ANNOUNCEMENT] MySQLdb-0.1.3 released
In-Reply-To: <38C7E7B9.ADD83BFA@lemburg.com>
Message-ID: <Pine.LNX.4.10.10003091433390.19506-100000@kenny.comstar.net>

On Thu, 9 Mar 2000, M.-A. Lemburg wrote:

> Andy Dustman wrote:
> > 
> > cursor.fetchrow(), of course, returns the result as a sequence of values,
> > usually a tuple. cursor.fetchrowDict() returns the result as a dictionary,
> > where the keys are the column names and the values are the column values.
> 
> How does this help with columns which are the result of
> a SQL function, e.g. select max(value) from table ?

You'd probably want to use AS to rename computed columns, e.g.,

SELECT MAX(value) AS max_value FROM table;
 
> Wouldn't the same functionality be available by simply
> merging the information from cursor.description and the
> result of .fetchone() (that's how my own abstract DB class works,
> BTW) ?

Yep, and that's essentially what fetchoneDict() is doing. fetchoneDict()
could have been implemented in Python to do that, but in this case, it's
done in C: conn.fetch_row_as_dict(), conn.fetch_rows_as_dict(n),
conn.fetch_all_rows_as_dict()); where conn is a _mysql.MYSQL connection
object. result.describe() produces the DB API description tuple from some
MySQL structures; where result is a _mySQL.MYSQL_RES result object. The
various fetch_XXX_as_dict() methods just get this information directly out
of some C data structures.

And, one of the things about MySQLdb is, since the top-level interface IS
written in Python, you can directly subclass the Connection and Cursor
objects (rather than writing wrappers), so really someone could have just
added this on as their own subclass. Let's just say it's there due to
popular demand, and documentated as non-portable.

-- 
andy dustman       |     programmer/analyst     |      comstar.net, inc.
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
"Therefore, sweet knights, if you may doubt your strength or courage, 
come no further, for death awaits you all, with nasty, big, pointy teeth!"




From crypt@ihug.co.nz  Fri Mar 10 03:39:28 2000
From: crypt@ihug.co.nz (crypt@ihug.co.nz)
Date: Fri, 10 Mar 2000 16:39:28 +1300
Subject: [DB-SIG] [ANNOUNCEMENT] MySQLdb-0.1.3 released
In-Reply-To: <Pine.LNX.4.10.10003091433390.19506-100000@kenny.comstar.net>; from adustman@comstar.net on Thu, Mar 09, 2000 at 02:46:49PM -0500
References: <38C7E7B9.ADD83BFA@lemburg.com> <Pine.LNX.4.10.10003091433390.19506-100000@kenny.comstar.net>
Message-ID: <20000310163928.B30684@python.localnet>

On 03/09 14:46  Andy Dustman was heard to utter:
> On Thu, 9 Mar 2000, M.-A. Lemburg wrote:
> 
> > Andy Dustman wrote:
> > > 
> > > cursor.fetchrow(), of course, returns the result as a sequence of values,
> > > usually a tuple. cursor.fetchrowDict() returns the result as a dictionary,
> > > where the keys are the column names and the values are the column values.
> > 
> > How does this help with columns which are the result of
> > a SQL function, e.g. select max(value) from table ?
> 
> You'd probably want to use AS to rename computed columns, e.g.,
> 
> SELECT MAX(value) AS max_value FROM table;
>  
> > Wouldn't the same functionality be available by simply
> > merging the information from cursor.description and the
> > result of .fetchone() (that's how my own abstract DB class works,
> > BTW) ?
> 
> Yep, and that's essentially what fetchoneDict() is doing. fetchoneDict()
> could have been implemented in Python to do that, but in this case, it's
> done in C: conn.fetch_row_as_dict(), conn.fetch_rows_as_dict(n),
> conn.fetch_all_rows_as_dict()); where conn is a _mysql.MYSQL connection
> object. result.describe() produces the DB API description tuple from some
> MySQL structures; where result is a _mySQL.MYSQL_RES result object. The
> various fetch_XXX_as_dict() methods just get this information directly out
> of some C data structures.
> 
> And, one of the things about MySQLdb is, since the top-level interface IS
> written in Python, you can directly subclass the Connection and Cursor
> objects (rather than writing wrappers), so really someone could have just
> added this on as their own subclass. Let's just say it's there due to
> popular demand, and documentated as non-portable.

I looked at doing this but was wanting to include the tablename as well
and discovered for some reason that the discription field does not seem
to include this.

Is there a good reason for this?

Joe.

-- 
=======================================================================
in real life: Joseph Skinner         |There's no such thing as a wizard
email: crypt@ihug.co.nz              |who minds his own business
       Analyst/Programmer            | - Berengis the Black
                                     |   Court Mage to the Earls Caeline
========================================================================



From harri.pasanen@trema.com  Fri Mar 10 08:30:47 2000
From: harri.pasanen@trema.com (Harri Pasanen)
Date: Fri, 10 Mar 2000 09:30:47 +0100
Subject: [DB-SIG] [ANNOUNCEMENT] MySQLdb-0.1.3 released
References: <38C7E7B9.ADD83BFA@lemburg.com> <Pine.LNX.4.10.10003091433390.19506-100000@kenny.comstar.net> <20000310163928.B30684@python.localnet>
Message-ID: <38C8B2B7.16AB7422@trema.com>

crypt@ihug.co.nz wrote:
> 
> On 03/09 14:46  Andy Dustman was heard to utter:
> > On Thu, 9 Mar 2000, M.-A. Lemburg wrote:
> >
> > > Andy Dustman wrote:
> > > >
> > > > cursor.fetchrow(), of course, returns the result as a sequence of values,
> > > > usually a tuple. cursor.fetchrowDict() returns the result as a dictionary,
> > > > where the keys are the column names and the values are the column values.
> > >
> > > How does this help with columns which are the result of
> > > a SQL function, e.g. select max(value) from table ?
> >
> > You'd probably want to use AS to rename computed columns, e.g.,
> >
> > SELECT MAX(value) AS max_value FROM table;
> >
> > > Wouldn't the same functionality be available by simply
> > > merging the information from cursor.description and the
> > > result of .fetchone() (that's how my own abstract DB class works,
> > > BTW) ?
> >
> > Yep, and that's essentially what fetchoneDict() is doing. fetchoneDict()
> > could have been implemented in Python to do that, but in this case, it's
> > done in C: conn.fetch_row_as_dict(), conn.fetch_rows_as_dict(n),
> > conn.fetch_all_rows_as_dict()); where conn is a _mysql.MYSQL connection
> > object. result.describe() produces the DB API description tuple from some
> > MySQL structures; where result is a _mySQL.MYSQL_RES result object. The
> > various fetch_XXX_as_dict() methods just get this information directly out
> > of some C data structures.
> >
> > And, one of the things about MySQLdb is, since the top-level interface IS
> > written in Python, you can directly subclass the Connection and Cursor
> > objects (rather than writing wrappers), so really someone could have just
> > added this on as their own subclass. Let's just say it's there due to
> > popular demand, and documentated as non-portable.
> 
> I looked at doing this but was wanting to include the tablename as well
> and discovered for some reason that the discription field does not seem
> to include this.
> 
> Is there a good reason for this?
> 

Your SQL query can be a join from multiple tables.  Or if the result set
comes from a stored procedure, you can't even look at your query to see
what tables are affected.

The result set is just value columns with their attributes.  Tables have
nothing to do with the result sets.

Disclaimer: I'm not familiar with MySQL, only with Sybase, but the same
concepts should apply.

-Harri


From mal@lemburg.com  Thu Mar  9 21:42:55 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 09 Mar 2000 22:42:55 +0100
Subject: [DB-SIG] [ANNOUNCEMENT] MySQLdb-0.1.3 released
References: <Pine.LNX.4.10.10003091433390.19506-100000@kenny.comstar.net>
Message-ID: <38C81ADF.36EE2BB4@lemburg.com>

Andy Dustman wrote:
> 
> On Thu, 9 Mar 2000, M.-A. Lemburg wrote:
> 
> > Andy Dustman wrote:
> > >
> > > cursor.fetchrow(), of course, returns the result as a sequence of values,
> > > usually a tuple. cursor.fetchrowDict() returns the result as a dictionary,
> > > where the keys are the column names and the values are the column values.
> >
> > How does this help with columns which are the result of
> > a SQL function, e.g. select max(value) from table ?
> 
> You'd probably want to use AS to rename computed columns, e.g.,
> 
> SELECT MAX(value) AS max_value FROM table;

Hmm, you're just moving complexity from Python into SQL, but...
anyways it's probably convenient to have :-)
 
> > Wouldn't the same functionality be available by simply
> > merging the information from cursor.description and the
> > result of .fetchone() (that's how my own abstract DB class works,
> > BTW) ?
> 
> Yep, and that's essentially what fetchoneDict() is doing. fetchoneDict()
> could have been implemented in Python to do that, but in this case, it's
> done in C: conn.fetch_row_as_dict(), conn.fetch_rows_as_dict(n),
> conn.fetch_all_rows_as_dict()); where conn is a _mysql.MYSQL connection
> object. result.describe() produces the DB API description tuple from some
> MySQL structures; where result is a _mySQL.MYSQL_RES result object. The
> various fetch_XXX_as_dict() methods just get this information directly out
> of some C data structures.
> 
> And, one of the things about MySQLdb is, since the top-level interface IS
> written in Python, you can directly subclass the Connection and Cursor
> objects (rather than writing wrappers), so really someone could have just
> added this on as their own subclass. Let's just say it's there due to
> popular demand, and documentated as non-portable.

Well, your Cursor and Connection object *are* already wrappers
around the C layer... ;-) I usually do the same for my ODBC
stuff: there are high level wrappers around the connection,
the tables, result set and rows -- all done in Python to make
reuse as easy as possible.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From hme@informatik.uni-rostock.de  Fri Mar 10 14:47:03 2000
From: hme@informatik.uni-rostock.de (hme@informatik.uni-rostock.de)
Date: Fri, 10 Mar 2000 15:47:03 +0100
Subject: [DB-SIG] DB API 2.0 OpenIngres Beta
Message-ID: <20000310154703.A26246@informatik.uni-rostock.de>

Hello,

it seems, that I am reaching a stable version of my OpenIngres module.
Are there people interested in beta testing it?  It was build and tested
with:
	-- CA Ingres 6.4 on Solaris 2.6
	-- CA OpenIngres 1.2 on Solaris 2.6
	-- CA Ingres II on SuSE Linux 6.3

Peace

Holger

-- 
Holger Meyer, Uni of Rostock, Dpt. of CS, DB Research Group
hm@guug.de, http://www.informatik.uni-rostock.de/~hme/


From bittneph@aston.ac.uk  Mon Mar 13 02:04:33 2000
From: bittneph@aston.ac.uk (Peter Bittner)
Date: Mon, 13 Mar 2000 02:04:33 +0000
Subject: [DB-SIG] Connect vs. connect
Message-ID: <38CC4CB1.32B6AFE9@aston.ac.uk>

Hi there!

> db = MySQLdb.connect(db='mydb',user='myuser',passwd='mypasswd')

Why is connect an function in MySQLdb, whereas in DCOracle it is a
constructor Connect. - Where is the API compatibility gone?

> db = DCOracle.Connect(username + '/' + pwd + '@' + system)

DCOracle supports the Python API 1.0 not 2.0, is that the reason?
Peter

| Peter H. Bittner
| International Student at Aston University
| e-mail: bittneph@aston.ac.uk
| web: http://beam.to/bimbo
+--------------------------


From mal@lemburg.com  Mon Mar 13 09:00:48 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 13 Mar 2000 10:00:48 +0100
Subject: [DB-SIG] Connect vs. connect
References: <38CC4CB1.32B6AFE9@aston.ac.uk>
Message-ID: <38CCAE40.32B8A35D@lemburg.com>

Peter Bittner wrote:
> 
> Hi there!
> 
> > db = MySQLdb.connect(db='mydb',user='myuser',passwd='mypasswd')
> 
> Why is connect an function in MySQLdb, whereas in DCOracle it is a
> constructor Connect. - Where is the API compatibility gone?
> 
> > db = DCOracle.Connect(username + '/' + pwd + '@' + system)
> 
> DCOracle supports the Python API 1.0 not 2.0, is that the reason?

No, DB API 1.0 states to use the name of the module as constructor.
DB API 2.0 defines .connect(). The name .Connect() is either DC's
own invention or came from early versions of the DB API 2.0.

FYI, mxODBC provides .connect() and an alias .Connect() as well
as the DB API 1.0 names for each of the subpackages, e.g.
ODBC.iODBC.iODBC(...).

> Peter
> 
> | Peter H. Bittner
> | International Student at Aston University
> | e-mail: bittneph@aston.ac.uk
> | web: http://beam.to/bimbo
> +--------------------------
> 
> _______________________________________________
> DB-SIG maillist  -  DB-SIG@python.org
> http://www.python.org/mailman/listinfo/db-sig

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From adustman@comstar.net  Mon Mar 13 14:31:40 2000
From: adustman@comstar.net (Andy Dustman)
Date: Mon, 13 Mar 2000 09:31:40 -0500 (EST)
Subject: [DB-SIG] Re: Connect vs. connect
In-Reply-To: <38CC4CB1.32B6AFE9@aston.ac.uk>
Message-ID: <Pine.LNX.4.10.10003130930460.30715-100000@kenny.comstar.net>

On Mon, 13 Mar 2000, Peter Bittner wrote:

> Hi there!
> 
> > db = MySQLdb.connect(db='mydb',user='myuser',passwd='mypasswd')
> 
> Why is connect an function in MySQLdb, whereas in DCOracle it is a
> constructor Connect. - Where is the API compatibility gone?
> 
> > db = DCOracle.Connect(username + '/' + pwd + '@' + system)
> 
> DCOracle supports the Python API 1.0 not 2.0, is that the reason?

In MySQLdb, connect = Connect = Connection. 

-- 
andy dustman       |     programmer/analyst     |      comstar.net, inc.
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
"Therefore, sweet knights, if you may doubt your strength or courage, 
come no further, for death awaits you all, with nasty, big, pointy teeth!"



From adustman@comstar.net  Mon Mar 13 19:54:28 2000
From: adustman@comstar.net (Andy Dustman)
Date: Mon, 13 Mar 2000 14:54:28 -0500 (EST)
Subject: [DB-SIG] Scrollable cursors
In-Reply-To: <20000222170123.A15232@trump.amber.org>
Message-ID: <Pine.LNX.4.10.10003131439240.31507-100000@kenny.comstar.net>

On Tue, 22 Feb 2000, Christopher Petrilli wrote:

> Cary Collett [cary@ratatosk.org] wrote:
> > 
> > For me LIMIT is the big one: 
> > 
> > SELECT ... LIMIT 4 (return the first 4 results)
> > SELECT ... LIMIT 3,5 (return the 4th through 9th rows)
> 
> Correct behaviour of scrollable cursors will get you this in a MUCH
> more advanced form :-)

Scrollable cursors are not (yet) part of the DB API spec. However, it
occurred to me in doing some MySQLdb updates that MySQL effectively has
scrollable cursors using mysql_data_seek(result, offset), where offset is
a relative offset. (Although, this is limited to clients that use
mysql_store_result(), which MySQLdb does, as opposed to
mysql_use_result(). Either way, the LIMIT SQL extension for MySQL will
reduce the number of rows which are send back to the client.)

So, are there any DB API interface which employ scrollable cursors to this
date? If not, I propose the following semantics:

cursor.seek(n) -- scrolls the cursor to row n, with the first row being 0.
If the database does not support seekable cursors, this method should not
be defined. If database cannot support seeking under current conditions,
it should raise NotSupportedError. (Similar to the cursor.rollback()
language)

Does this sound okay? The next release is not immininent, but I'd just as
soon not have to change it if I don't have to.

(Incidentally, the next version of MySQLdb will recognize when MySQL
supports transactions, and define commit() and rollback() accordingly.)

-- 
andy dustman       |     programmer/analyst     |      comstar.net, inc.
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
"Therefore, sweet knights, if you may doubt your strength or courage, 
come no further, for death awaits you all, with nasty, big, pointy teeth!"



From adustman@comstar.net  Mon Mar 13 20:54:24 2000
From: adustman@comstar.net (Andy Dustman)
Date: Mon, 13 Mar 2000 15:54:24 -0500 (EST)
Subject: [DB-SIG] Re: Scrollable cursors
In-Reply-To: <Pine.LNX.4.10.10003131439240.31507-100000@kenny.comstar.net>
Message-ID: <Pine.LNX.4.10.10003131542050.31507-100000@kenny.comstar.net>

On Mon, 13 Mar 2000, Andy Dustman wrote:

> cursor.seek(n) -- scrolls the cursor to row n, with the first row being 0.
> If the database does not support seekable cursors, this method should not
> be defined. If database cannot support seeking under current conditions,
> it should raise NotSupportedError. (Similar to the cursor.rollback()
> language)

In actually writing the code, I would amend this to:

cursor.seek(n, whence=0) -- if whence=0, scrolls the cursor to absolute
row n, else perform a relative scroll. There are some difficulties in
doing the relative scroll, but I hope I can get around them.

-- 
andy dustman       |     programmer/analyst     |      comstar.net, inc.
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
"Therefore, sweet knights, if you may doubt your strength or courage, 
come no further, for death awaits you all, with nasty, big, pointy teeth!"



From battery841@excite.com  Wed Mar 15 04:23:00 2000
From: battery841@excite.com (battery841@excite.com)
Date: Tue, 14 Mar 2000 20:23:00 -0800 (PST)
Subject: [DB-SIG] mdb
Message-ID: <16541750.953094180895.JavaMail.imail@dotty.excite.com>

Hey,
	I have been having problems with SQL/Python integration as of late.  My
friend was saying I should check to see if Python has support for mdb.
Thanks
Kevin





_______________________________________________________
Get 100% FREE Internet Access powered by Excite
Visit http://freelane.excite.com/freeisp



From battery841@excite.com  Wed Mar 15 04:26:10 2000
From: battery841@excite.com (battery841@excite.com)
Date: Tue, 14 Mar 2000 20:26:10 -0800 (PST)
Subject: [DB-SIG] support for dbm
Message-ID: <32503598.953094370478.JavaMail.imail@dotty.excite.com>

Hey,
	Okay, my friend lied to me.  he said he was thinking mdb, when in fact it
was dbm.  So, let me restate my question.  Does Python have support for dbm?
:)
Thanks
Kevin





_______________________________________________________
Get 100% FREE Internet Access powered by Excite
Visit http://freelane.excite.com/freeisp



From mal@lemburg.com  Tue Mar 14 12:53:55 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 14 Mar 2000 13:53:55 +0100
Subject: [DB-SIG] Scrollable cursors
References: <Pine.LNX.4.10.10003131439240.31507-100000@kenny.comstar.net>
Message-ID: <38CE3663.AE1E1A6D@lemburg.com>

Andy Dustman wrote:
> 
> On Tue, 22 Feb 2000, Christopher Petrilli wrote:
> 
> > Cary Collett [cary@ratatosk.org] wrote:
> > >
> > > For me LIMIT is the big one:
> > >
> > > SELECT ... LIMIT 4 (return the first 4 results)
> > > SELECT ... LIMIT 3,5 (return the 4th through 9th rows)
> >
> > Correct behaviour of scrollable cursors will get you this in a MUCH
> > more advanced form :-)
> 
> Scrollable cursors are not (yet) part of the DB API spec. However, it
> occurred to me in doing some MySQLdb updates that MySQL effectively has
> scrollable cursors using mysql_data_seek(result, offset), where offset is
> a relative offset. (Although, this is limited to clients that use
> mysql_store_result(), which MySQLdb does, as opposed to
> mysql_use_result(). Either way, the LIMIT SQL extension for MySQL will
> reduce the number of rows which are send back to the client.)
> 
> So, are there any DB API interface which employ scrollable cursors to this
> date? If not, I propose the following semantics:
> 
> cursor.seek(n) -- scrolls the cursor to row n, with the first row being 0.
> If the database does not support seekable cursors, this method should not
> be defined. If database cannot support seeking under current conditions,
> it should raise NotSupportedError. (Similar to the cursor.rollback()
> language)

Change this to "raises an AttributeError or a NotSupportedError"
-- this is how the other APIs work too: if the database doesn't
provide this interface, don't define the method; if this information
is dynamic, raise a NotSupportedError when it is called.

BTW, ODBC defines these fetch operations:

SQL_FETCH_NEXT 
SQL_FETCH_PRIOR 
SQL_FETCH_FIRST 
SQL_FETCH_LAST 
SQL_FETCH_ABSOLUTE 
SQL_FETCH_RELATIVE 

Most of these should be doable with your addition of whence,
but there is no way to say "jump to last row". ODBC 3.0 has
a nice API for this too: SQLFetchScroll() which I could use
(the older one SQLExtendedFetch() is rather complicated to
use right...).

> cursor.seek(n, whence=0) -- if whence=0, scrolls the cursor to absolute
> row n, else perform a relative scroll. There are some difficulties in
> doing the relative scroll, but I hope I can get around them.

> Does this sound okay? The next release is not immininent, but I'd just as
> soon not have to change it if I don't have to.

Would be cool indeed :-)

> (Incidentally, the next version of MySQLdb will recognize when MySQL
> supports transactions, and define commit() and rollback() accordingly.)

Since when does MySQL support transactions ? (I would be very
interested in this...)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From db-sig@python.org  Wed Mar 15 13:27:16 2000
From: db-sig@python.org (D'Arcy J.M. Cain)
Date: Wed, 15 Mar 2000 08:27:16 -0500 (EST)
Subject: [DB-SIG] support for dbm
In-Reply-To: <32503598.953094370478.JavaMail.imail@dotty.excite.com> from "battery841@excite.com" at "Mar 14, 2000 08:26:10 pm"
Message-ID: <m12VDpU-000AXZC@druid.net>

Thus spake battery841@excite.com
> 	Okay, my friend lied to me.  he said he was thinking mdb, when in fact it
> was dbm.  So, let me restate my question.  Does Python have support for dbm?

Absolutely.  http://www.python.org/doc/current/lib/module-dbm.html.  Look
into shelve as well for a nice interface to [g]dbm.


-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.


From adustman@comstar.net  Wed Mar 15 15:12:59 2000
From: adustman@comstar.net (Andy Dustman)
Date: Wed, 15 Mar 2000 10:12:59 -0500 (EST)
Subject: [DB-SIG] Scrollable cursors
In-Reply-To: <38CE3663.AE1E1A6D@lemburg.com>
Message-ID: <Pine.LNX.4.10.10003150955050.24397-100000@kenny.comstar.net>

On Tue, 14 Mar 2000, M.-A. Lemburg wrote:

> Andy Dustman wrote:
> > 
> > cursor.seek(n) -- scrolls the cursor to row n, with the first row being 0.
> > If the database does not support seekable cursors, this method should not
> > be defined. If database cannot support seeking under current conditions,
> > it should raise NotSupportedError. (Similar to the cursor.rollback()
> > language)
> 
> Change this to "raises an AttributeError or a NotSupportedError"
> -- this is how the other APIs work too: if the database doesn't
> provide this interface, don't define the method; if this information
> is dynamic, raise a NotSupportedError when it is called.

Uh, ok.
 
> > (Incidentally, the next version of MySQLdb will recognize when MySQL
> > supports transactions, and define commit() and rollback() accordingly.)
> 
> Since when does MySQL support transactions ? (I would be very
> interested in this...)

It doesn't, yet. I have heard they are coming soon, though, in 3.23.

Problems I have encountered implementing this:

mysql_data_seek(n) seeks on the result to the absolute row n.
mysql_row_seek(row) sets the cursor position to row, where row is a
pointer to the row in memory. mysql_row_tell(row) returns the current row
for later use by mysql_row_seek(). So no method here for relative
addressing. This prompted me to examine the MySQL code. The rows are
stored in memory as a singly-linked list, which is great if you never have
to seek. mysql_data_seek() starts at the beginning of the chain and simply
advances down the chain (in memory, of course) until it is at the correct
row. So forget about this happening in any efficient way.

It would be better (and I may very likely implement this) to simply fetch
all the rows and store them in the cursor and operate on those, because
the result object could then be freed at that point. None of the seeking
stuff has any chance of working if mysql_use_result() was used instead of
mysql_store_result(), anyway. This would probably mean two different
cursor types to be efficient, but this would not be obvious from the
interface (done by cursor()).

-- 
andy dustman       |     programmer/analyst     |      comstar.net, inc.
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
"Therefore, sweet knights, if you may doubt your strength or courage, 
come no further, for death awaits you all, with nasty, big, pointy teeth!"



From mal@lemburg.com  Wed Mar 15 16:07:49 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 15 Mar 2000 17:07:49 +0100
Subject: [DB-SIG] Scrollable cursors
References: <Pine.LNX.4.10.10003150955050.24397-100000@kenny.comstar.net>
Message-ID: <38CFB555.459DA153@lemburg.com>

Andy Dustman wrote:
> 
> On Tue, 14 Mar 2000, M.-A. Lemburg wrote:
> 
> > Andy Dustman wrote:
> > >
> > > cursor.seek(n) -- scrolls the cursor to row n, with the first row being 0.
> > > If the database does not support seekable cursors, this method should not
> > > be defined. If database cannot support seeking under current conditions,
> > > it should raise NotSupportedError. (Similar to the cursor.rollback()
> > > language)
> >
> > Change this to "raises an AttributeError or a NotSupportedError"
> > -- this is how the other APIs work too: if the database doesn't
> > provide this interface, don't define the method; if this information
> > is dynamic, raise a NotSupportedError when it is called.
> 
> Uh, ok.
> 
> > > (Incidentally, the next version of MySQLdb will recognize when MySQL
> > > supports transactions, and define commit() and rollback() accordingly.)
> >
> > Since when does MySQL support transactions ? (I would be very
> > interested in this...)
> 
> It doesn't, yet. I have heard they are coming soon, though, in 3.23.

Wow, now that would be *cool*.
 
> Problems I have encountered implementing this:
> 
> mysql_data_seek(n) seeks on the result to the absolute row n.
> mysql_row_seek(row) sets the cursor position to row, where row is a
> pointer to the row in memory. mysql_row_tell(row) returns the current row
> for later use by mysql_row_seek(). So no method here for relative
> addressing. This prompted me to examine the MySQL code. The rows are
> stored in memory as a singly-linked list, which is great if you never have
> to seek. mysql_data_seek() starts at the beginning of the chain and simply
> advances down the chain (in memory, of course) until it is at the correct
> row. So forget about this happening in any efficient way.
> 
> It would be better (and I may very likely implement this) to simply fetch
> all the rows and store them in the cursor and operate on those, because
> the result object could then be freed at that point. None of the seeking
> stuff has any chance of working if mysql_use_result() was used instead of
> mysql_store_result(), anyway. This would probably mean two different
> cursor types to be efficient, but this would not be obvious from the
> interface (done by cursor()).

Hmm, reminds me of many postings on the MyODBC list... MySQL
doesn't support server side cursors and your findings probably
relate to this defficiency.

OTOH, client side cursors don't help much w/r to performance
and reduction of network bandwidth... perhaps you should
wait until MySQL has server side cursors ?!

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From barrie@rockhopper.com  Thu Mar 16 00:40:57 2000
From: barrie@rockhopper.com (Barrie Selack)
Date: Wed, 15 Mar 2000 19:40:57 -0500
Subject: [DB-SIG] DB/2 for Python
Message-ID: <38D02D88.CE82DFD6@rockhopper.com>

Is there any work being done in the DB/2 area ?

Thanks,

Barrie Selack




From petrilli@amber.org  Thu Mar 16 01:03:02 2000
From: petrilli@amber.org (Christopher Petrilli)
Date: Wed, 15 Mar 2000 20:03:02 -0500
Subject: [DB-SIG] DB/2 for Python
In-Reply-To: <38D02D88.CE82DFD6@rockhopper.com>; from barrie@rockhopper.com on Wed, Mar 15, 2000 at 07:40:57PM -0500
References: <38D02D88.CE82DFD6@rockhopper.com>
Message-ID: <20000315200302.A10231@trump.amber.org>

Barrie Selack [barrie@rockhopper.com] wrote:
> Is there any work being done in the DB/2 area ?

You can use mxODBC to link with the DB/2 CLI libraries.  We (Digital 
Creations) are working on a Zope level interface, but it's not high
priority since a customer backed out of using DB/2 and went to Oracle...
guh.

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org


From petrilli@amber.org  Thu Mar 16 15:54:10 2000
From: petrilli@amber.org (Christopher Petrilli)
Date: Thu, 16 Mar 2000 10:54:10 -0500
Subject: [DB-SIG] Scrollable cursors
In-Reply-To: <38CFB555.459DA153@lemburg.com>; from mal@lemburg.com on Wed, Mar 15, 2000 at 05:07:49PM +0100
References: <Pine.LNX.4.10.10003150955050.24397-100000@kenny.comstar.net> <38CFB555.459DA153@lemburg.com>
Message-ID: <20000316105410.B12050@trump.amber.org>

M.-A. Lemburg [mal@lemburg.com] wrote:
> > It doesn't, yet. I have heard they are coming soon, though, in 3.23.
> 
> Wow, now that would be *cool*.

My understanding is it will be "optional" on a per-table (or database)
level.  This is cool, but I'm going to bet that when turned on they're
down to the same speed as say PostgreSQL.  Transactions are expensive,
but a necessary thing in a lot of applicatons.  

> Hmm, reminds me of many postings on the MyODBC list... MySQL
> doesn't support server side cursors and your findings probably
> relate to this defficiency.
> 
> OTOH, client side cursors don't help much w/r to performance
> and reduction of network bandwidth... perhaps you should
> wait until MySQL has server side cursors ?!

Client Side cursors are effectively pointless.  Most of the time you
use cursors for reducing memory footprint as well.  If you have a table
that you need to operate on that has 1M rows, you don't want to have
to suck all of them back in at once...in Oracle for example, you can
controll the cursor bblock-size.  This is very helpful.

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org


From hniksic@iskon.hr  Fri Mar 17 14:05:41 2000
From: hniksic@iskon.hr (Hrvoje Niksic)
Date: 17 Mar 2000 15:05:41 +0100
Subject: [DB-SIG] Postgres DB API-compliant Python access
Message-ID: <9t9hfe5vgi2.fsf@mraz.iskon.hr>

This list is probably not the right place for this question, but
anyway...

I need to access the PostgreSQL database from Python.  However, it
seems that the default Python wrapper is not DB-compliant.  If at all
possible, I'd really like to avoid learning yet another SQL wrapper
API.  (And besides, I have some DB-based MySQL code that I'd like to
convert.)

I noticed that Postgres supports ODBC.  Is that known to work with
mxODBC?  Does one need a driver manager as well?  Are there efficiency
issues?

Is the default Python wrapper scheduled to be made DB-compliant soon?
In that case, I could wait for that, and/or participate in testing.


From mal@lemburg.com  Fri Mar 17 14:36:31 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 17 Mar 2000 15:36:31 +0100
Subject: [DB-SIG] Postgres DB API-compliant Python access
References: <9t9hfe5vgi2.fsf@mraz.iskon.hr>
Message-ID: <38D242EF.2F159B7F@lemburg.com>

Hrvoje Niksic wrote:
> 
> This list is probably not the right place for this question, but
> anyway...
> 
> I need to access the PostgreSQL database from Python.  However, it
> seems that the default Python wrapper is not DB-compliant.  If at all
> possible, I'd really like to avoid learning yet another SQL wrapper
> API.  (And besides, I have some DB-based MySQL code that I'd like to
> convert.)
> 
> I noticed that Postgres supports ODBC.  Is that known to work with
> mxODBC?  Does one need a driver manager as well?  Are there efficiency
> issues?

Yes...

create a new subpackage PostgreSQL as documented; then add this to
Setup:

#### ODBC interface for PostgreSQL 6.5.x ODBC driver
#
# Note: you will have to fix the paths to point to your installation
# directories.
#
        -DPostgreSQL \
        -DDONT_HAVE_SQLDescribeParam \
        -I/usr/local/pgsql/include/iodbc \
        /usr/local/pgsql/lib/libpsqlodbc.so
#
#

and a new #ifdef level to mxODBC.h:

#ifdef PostgreSQL
/* PostgreSQL ODBC driver */
# include "iodbc.h"
# include "isql.h"
# include "isqlext.h"
# define MXODBC_INTERFACENAME "PostgreSQL ODBC"
#else

...

#endif

The __init__.py file of the subpackage probably also needs
some tweaking.

Don't know how efficient the PostgreSQL ODBC interface is,
but at least you get DB API compliant access this way.

> Is the default Python wrapper scheduled to be made DB-compliant soon?
> In that case, I could wait for that, and/or participate in testing.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From hme@informatik.uni-rostock.de  Wed Mar 22 13:25:05 2000
From: hme@informatik.uni-rostock.de (hme@informatik.uni-rostock.de)
Date: Wed, 22 Mar 2000 14:25:05 +0100
Subject: [DB-SIG] Date/Time question
Message-ID: <20000322142505.A6814@informatik.uni-rostock.de>

Hello,

implementing my Ingres module, I run across the following
implementation aspects:  According to the DB API 2.0, there are methods
for building several time/date value combinations.  But the DATETIME
object seems to represent absolute values only.

Is this correct?  If so, has someone made a proposal for representing
time intervals.  Since Ingres supports arithmetic on absolute and
relative time, it would be nice to have both.

Most database systems, that support temporal data, have a notation of
`now' and `today', why these values not make default parameters?  As
far as I know some Systems internally represent date/time as strings
(Informix, Ingres).  Since there's no string parameter to the date/time
methods, conversion takes place two times.  Another side effect would
be, that `now' and `today' are evaluated at execution time, not at
PREPARE.

Peace

Holger

-- 
Holger Meyer, Uni of Rostock, Dpt. of CS, DB Research Group
hm@guug.de, http://www.informatik.uni-rostock.de/~hme/


From petrilli@amber.org  Wed Mar 22 16:42:49 2000
From: petrilli@amber.org (Christopher Petrilli)
Date: Wed, 22 Mar 2000 11:42:49 -0500
Subject: [DB-SIG] Oracle 8i Setup file
Message-ID: <20000322114249.A4897@trump.amber.org>

I know this sin't the most interesing thing everyone has seen this
year, but I've posted a Setup file for Oracle8i and DCOracle on my
page on zope.org.  You can find it here:

     http://www.zope.org/Members/petrilli/Oracle8i

This works great for us, and makes a MUCH smaller executable.

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org


From deirdre@deirdre.net  Wed Mar 22 17:43:21 2000
From: deirdre@deirdre.net (Deirdre Saoirse)
Date: Wed, 22 Mar 2000 09:43:21 -0800 (PST)
Subject: [DB-SIG] Date/Time question
In-Reply-To: <20000322142505.A6814@informatik.uni-rostock.de>
Message-ID: <Pine.LNX.4.10.10003220943000.2268-100000@rockhopper.deirdre.org>

On Wed, 22 Mar 2000 hme@informatik.uni-rostock.de wrote:

> Is this correct?  If so, has someone made a proposal for representing
> time intervals.  Since Ingres supports arithmetic on absolute and
> relative time, it would be nice to have both.

You might look and see if mxDateTime meets your needs.

-- 
_Deirdre   *   http://www.linuxcabal.org   *   http://www.deirdre.net
       "In /dev/null, no one can hear you scream"



From sgendler@impossible.com  Thu Mar 23 09:17:19 2000
From: sgendler@impossible.com (Sam Gendler)
Date: Thu, 23 Mar 2000 01:17:19 -0800
Subject: [DB-SIG] quick help with auto increment fields
Message-ID: <38D9E11F.C22EF6DE@impossible.com>

I am new to using databases from within python (outside of Zope that
is), and in addition, I am being forced to jump into it while
simultaneously jumping into pythonwin and odbc, so please bear with me.

I have successfully connected to an ODBC data source (although it failed
when I tried to connect to SQL server 7.0, it worked with Access), and I
can execute SELECT queries no problem.  However, my current app really
only needs to do INSERT queries, anyway.  I am curious as to whether the
cursor returns the value of an auto incrementing field when doing an
insert, or if there is any way to get such information.

Also, if anyone has any advice on connecting to SQL server 7.0, that
would be great.  I am currently using the odbc module, rather than the
calldll method, since I am not terribly familiar with the windows api to
begin with.  I will use calldll if I have to, though.

Please respond directly, as I was getting no response from the list
subscription form.  I will continue attempting to subscribe.

--sam



From sgendler@impossible.com  Thu Mar 23 09:23:50 2000
From: sgendler@impossible.com (Sam Gendler)
Date: Thu, 23 Mar 2000 01:23:50 -0800
Subject: [DB-SIG] resend: quick help with auto increment fields
Message-ID: <38D9E2A6.6523A079@impossible.com>

OK, now I am subscribed, so I am sending it again.  Sorry for the
redundancy, but I was unsure if it would go through before I subscribed.

--sam

I am new to using databases from within python (outside of Zope that
is), and in addition, I am being forced to jump into it while
simultaneously jumping into pythonwin and odbc, so please bear with me.

I have successfully connected to an ODBC data source (although it failed
when I tried to connect to SQL server 7.0, it worked with Access), and I
can execute SELECT queries no problem.  However, my current app really
only needs to do INSERT queries, anyway.  I am curious as to whether the
cursor returns the value of an auto incrementing field when doing an
insert, or if there is any way to get such information.

Also, if anyone has any advice on connecting to SQL server 7.0, that
would be great.  I am currently using the odbc module, rather than the
calldll method, since I am not terribly familiar with the windows api to
begin with.  I will use calldll if I have to, though.

Please respond directly, as I was getting no response from the list
subscription form.  I will continue attempting to subscribe.

--sam


From mal@lemburg.com  Thu Mar 23 10:10:26 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 23 Mar 2000 11:10:26 +0100
Subject: [DB-SIG] quick help with auto increment fields
References: <38D9E11F.C22EF6DE@impossible.com>
Message-ID: <38D9ED92.46102EDA@lemburg.com>

Sam Gendler wrote:
> 
> I am new to using databases from within python (outside of Zope that
> is), and in addition, I am being forced to jump into it while
> simultaneously jumping into pythonwin and odbc, so please bear with me.
> 
> I have successfully connected to an ODBC data source (although it failed
> when I tried to connect to SQL server 7.0, it worked with Access), and I
> can execute SELECT queries no problem.  However, my current app really
> only needs to do INSERT queries, anyway.  I am curious as to whether the
> cursor returns the value of an auto incrementing field when doing an
> insert, or if there is any way to get such information.

Since the odbc module in PythonWin is DB API 1.0 compatible,
the cursor.execute() will (if anything at all) only return
the number of rows inserted in your case. DB API 2.0 compatible
interfaces return this information via cursor.rowcount.

The only way to get at the value of the last inserted
auto-incremented field is AFAIK through some SQL function.
Since there is no standard on these fields, you'll have to
consult your DB's docs for details. E.g. MySQL has such a function:
LAST_INSERT_ID().

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From mal@lemburg.com  Thu Mar 23 10:27:24 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 23 Mar 2000 11:27:24 +0100
Subject: [DB-SIG] Date/Time question
References: <20000322142505.A6814@informatik.uni-rostock.de>
Message-ID: <38D9F18C.98C248D0@lemburg.com>

hme@informatik.uni-rostock.de wrote:
> 
> Hello,
> 
> implementing my Ingres module, I run across the following
> implementation aspects:  According to the DB API 2.0, there are methods
> for building several time/date value combinations.  But the DATETIME
> object seems to represent absolute values only.

DATETIME is a type object, it doesn't refer to an object holding
date/time values. In fact, there can be different objects for
absolute date/time and relative date/time values. DATETIME and the
other type objects are only used to group the type information in
the cursor's description field in categories... e.g. mxODBC
usually maps many different type codes to one type object (that's
why the DB API spec. says that type codes in the description
field must only *compare* equal to one of the type objects -- it
allows the interface designer to create type objects which
compare equal to a class of type codes rather than just one
value). See the DBAPITypeObject class in the implementation
notes of the DB API 2.0 spec for an example.
 
> Is this correct?  If so, has someone made a proposal for representing
> time intervals.  Since Ingres supports arithmetic on absolute and
> relative time, it would be nice to have both.

Time intervals are not a SQL standard yet, AFAIK. You can still
support them in your interface, but they won't be portable
between DBs -- then again: its hard to write DB independent
code anyway..
 
> Most database systems, that support temporal data, have a notation of
> `now' and `today', why these values not make default parameters? 

I'm not sure I understand what you mean here... why should all
date/time columns default to now() or today() ?

> As
> far as I know some Systems internally represent date/time as strings
> (Informix, Ingres).  Since there's no string parameter to the date/time
> methods, conversion takes place two times. 

Why ? You could implement the date/time constructors in such
a way that also accepts string on input... note that the
constructors are only meant for the input side of the interface
(and then mostly because some DBs don't provide column type
information in their APIs). The output side is not defined and
usually varies between DBs.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From hme@informatik.uni-rostock.de  Thu Mar 23 12:37:16 2000
From: hme@informatik.uni-rostock.de (hme@informatik.uni-rostock.de)
Date: Thu, 23 Mar 2000 13:37:16 +0100
Subject: [DB-SIG] Date/Time question
In-Reply-To: <38D9F18C.98C248D0@lemburg.com>; from M.-A. Lemburg on Thu, Mar 23, 2000 at 11:27:24AM +0100
References: <20000322142505.A6814@informatik.uni-rostock.de> <38D9F18C.98C248D0@lemburg.com>
Message-ID: <20000323133716.A7900@informatik.uni-rostock.de>

You (M.-A. Lemburg) wrote:
> hme@informatik.uni-rostock.de wrote:
> > implementing my Ingres module, I run across the following
> > implementation aspects:  According to the DB API 2.0, there are methods
> > for building several time/date value combinations.  But the DATETIME
> > object seems to represent absolute values only.
> 
> DATETIME is a type object, it doesn't refer to an object holding
> date/time values. In fact, there can be different objects for
> absolute date/time and relative date/time values. DATETIME and the
> other type objects are only used to group the type information in
> the cursor's description field in categories... e.g. mxODBC
> usually maps many different type codes to one type object (that's
> why the DB API spec. says that type codes in the description
> field must only *compare* equal to one of the type objects -- it
> allows the interface designer to create type objects which
> compare equal to a class of type codes rather than just one
> value). See the DBAPITypeObject class in the implementation
> notes of the DB API 2.0 spec for an example.

Thanks for clarifying this.

> > Is this correct?  If so, has someone made a proposal for representing
> > time intervals.  Since Ingres supports arithmetic on absolute and
> > relative time, it would be nice to have both.
> 
> Time intervals are not a SQL standard yet, AFAIK. You can still
> support them in your interface, but they won't be portable
> between DBs -- then again: its hard to write DB independent
> code anyway..
>  
> > Most database systems, that support temporal data, have a notation of
> > `now' and `today', why these values not make default parameters? 
> 
> I'm not sure I understand what you mean here... why should all
> date/time columns default to now() or today() ?

If no values are supplied to input parameter of type DATETIME, e.g.
just using Date() as an input parameter.  When using `now' the dbms is
substituting transaction time, in contrast to building a default
paramter (e.g. using UNIX time()) at PREPARE time.

> > As
> > far as I know some Systems internally represent date/time as strings
> > (Informix, Ingres).  Since there's no string parameter to the date/time
> > methods, conversion takes place two times. 
> 
> Why ? You could implement the date/time constructors in such
> a way that also accepts string on input... note that the
> constructors are only meant for the input side of the interface

Yup, but if it's O.K. to overload the constructors, than it works.
So the API is more a at-least-thing?

> (and then mostly because some DBs don't provide column type
> information in their APIs). The output side is not defined and
> usually varies between DBs.

But the type_code should compare equal to one of the types defined by
the API?

Holger

-- 
Holger Meyer, Uni of Rostock, Dpt. of CS, DB Research Group
hm@guug.de, http://www.informatik.uni-rostock.de/~hme/


From mal@lemburg.com  Thu Mar 23 12:58:16 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 23 Mar 2000 13:58:16 +0100
Subject: [DB-SIG] Date/Time question
References: <20000322142505.A6814@informatik.uni-rostock.de> <38D9F18C.98C248D0@lemburg.com> <20000323133716.A7900@informatik.uni-rostock.de>
Message-ID: <38DA14E8.80B74B6A@lemburg.com>

hme@informatik.uni-rostock.de wrote:
> ...
> > > Most database systems, that support temporal data, have a notation of
> > > `now' and `today', why these values not make default parameters?
> >
> > I'm not sure I understand what you mean here... why should all
> > date/time columns default to now() or today() ?
> 
> If no values are supplied to input parameter of type DATETIME, e.g.
> just using Date() as an input parameter.  When using `now' the dbms is
> substituting transaction time, in contrast to building a default
> paramter (e.g. using UNIX time()) at PREPARE time.

Hmm, I guess you could add this to your implementation, but
it would not be portable.
 
> > > As
> > > far as I know some Systems internally represent date/time as strings
> > > (Informix, Ingres).  Since there's no string parameter to the date/time
> > > methods, conversion takes place two times.
> >
> > Why ? You could implement the date/time constructors in such
> > a way that also accepts string on input... note that the
> > constructors are only meant for the input side of the interface
> 
> Yup, but if it's O.K. to overload the constructors, than it works.
> So the API is more a at-least-thing?

Right. It tries to provide the essentials and a few guidelines
on how to implement extensions. IMHO, it does a pretty good
job at that...
 
> > (and then mostly because some DBs don't provide column type
> > information in their APIs). The output side is not defined and
> > usually varies between DBs.
> 
> But the type_code should compare equal to one of the types defined by
> the API?

Well, that depends... if you have a column type which does
not fall into the given categories, it is probably ok to define
a new interface dependent one. In general, you shouldn't refrain from
implementing a feature just because the DB API doesn't specify
it -- the only thing to watch out for is not to use different
semantics for things already defined in the spec...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From sgendler@impossible.com  Thu Mar 23 19:20:33 2000
From: sgendler@impossible.com (Sam Gendler)
Date: Thu, 23 Mar 2000 11:20:33 -0800
Subject: [DB-SIG] sql sensitive characters question
Message-ID: <38DA6E81.BBA3E763@impossible.com>

Is there a standardized function for escaping characters with
alternative meaning in SQL?

Also, has anyone had to play with a standard HTTP date (Thu, 23 Mar 2000
07:53:36 GMT) within Windows.  There doesn not appear to be a strptime
function for date conversion.  Do I have to just parse it manually, or
am I missing something.  I ask on this list, as the whole Date question
is always such a pain in the a** in databases, and I am having the
problem in a database context.

--sam



From sgendler@impossible.com  Thu Mar 23 20:28:46 2000
From: sgendler@impossible.com (Sam Gendler)
Date: Thu, 23 Mar 2000 12:28:46 -0800
Subject: [DB-SIG] quick help with auto increment fields
References: <38D9E11F.C22EF6DE@impossible.com> <38D9ED92.46102EDA@lemburg.com>
Message-ID: <38DA7E7D.E94D08C2@impossible.com>

>
>
> Since the odbc module in PythonWin is DB API 1.0 compatible,
> the cursor.execute() will (if anything at all) only return
> the number of rows inserted in your case. DB API 2.0 compatible
> interfaces return this information via cursor.rowcount.

Thinking that you were implying that I would have access to the last inserted
id if I used a dbi 2.0 compliant module, I grabbed mxODBC.  I am still unable
to access the last inserted id.  The rowcount variable always returns 1 after
an insert, but even worse than that, the row wasn't actually inserted.  Do I
still need to close the cursor and set it to null before the insert is
actually completed, as in the pythonwin odbc module?  Code follows:

conn = ODBC.Windows.Connect('AccessTest','','')
cur = conn.cursor()
cur.execute(sql1)
print cur.rowcount

cur.execute returns 1 and cur.rowcount is 1, but the new values do not show up
in the database.

Select statements do work, by the way.

--sam



>
>
> The only way to get at the value of the last inserted
> auto-incremented field is AFAIK through some SQL function.
> Since there is no standard on these fields, you'll have to
> consult your DB's docs for details. E.g. MySQL has such a function:
> LAST_INSERT_ID().
>
> --
> Marc-Andre Lemburg
> ______________________________________________________________________
> Business:                                      http://www.lemburg.com/
> Python Pages:                           http://www.lemburg.com/python/



From mal@lemburg.com  Thu Mar 23 21:10:18 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 23 Mar 2000 22:10:18 +0100
Subject: [DB-SIG] quick help with auto increment fields
References: <38D9E11F.C22EF6DE@impossible.com> <38D9ED92.46102EDA@lemburg.com> <38DA7E7D.E94D08C2@impossible.com>
Message-ID: <38DA883A.C939938A@lemburg.com>

Sam Gendler wrote:
> 
> >
> >
> > Since the odbc module in PythonWin is DB API 1.0 compatible,
> > the cursor.execute() will (if anything at all) only return
> > the number of rows inserted in your case. DB API 2.0 compatible
> > interfaces return this information via cursor.rowcount.
> 
> Thinking that you were implying that I would have access to the last inserted
> id if I used a dbi 2.0 compliant module, I grabbed mxODBC. 

I wasn't implying that... mxODBC doesn't have access to any
DB magic either -- it's just plain ODBC at the works there :-)

> I am still unable
> to access the last inserted id.  The rowcount variable always returns 1 after
> an insert, but even worse than that, the row wasn't actually inserted. 

You probably forgot to commit the changes... call cursor.commit()
after the insert. The data should then be written to the database
for everyone to see.

> Do I
> still need to close the cursor and set it to null before the insert is
> actually completed, as in the pythonwin odbc module?  Code follows:
> 
> conn = ODBC.Windows.Connect('AccessTest','','')
> cur = conn.cursor()
> cur.execute(sql1)
> print cur.rowcount
> 
> cur.execute returns 1 and cur.rowcount is 1, but the new values do not show up
> in the database.
> 
> Select statements do work, by the way.
> 
> --sam
> 
> >
> >
> > The only way to get at the value of the last inserted
> > auto-incremented field is AFAIK through some SQL function.
> > Since there is no standard on these fields, you'll have to
> > consult your DB's docs for details. E.g. MySQL has such a function:
> > LAST_INSERT_ID().
> >
> > --
> > Marc-Andre Lemburg
> > ______________________________________________________________________
> > Business:                                      http://www.lemburg.com/
> > Python Pages:                           http://www.lemburg.com/python/
> 
> _______________________________________________
> DB-SIG maillist  -  DB-SIG@python.org
> http://www.python.org/mailman/listinfo/db-sig

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From amodeum@juno.com  Thu Mar 23 23:03:53 2000
From: amodeum@juno.com (Collin J Docterman)
Date: Thu, 23 Mar 2000 18:03:53 -0500
Subject: [DB-SIG] Help! I'm a beginner
Message-ID: <20000323.180354.-3675263.0.amodeum@juno.com>

I need some tips on how to use python and things to help me get started.
I'm a new person at this. 
							Collin
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.


From vranicar@fnal.gov  Thu Mar 23 23:30:07 2000
From: vranicar@fnal.gov (Matthew Vranicar)
Date: Thu, 23 Mar 2000 17:30:07 -0600
Subject: [DB-SIG] Oracle 8i Setup file
Message-ID: <38DAA8FF.67FF2A1A@fnal.gov>

Chris,
Thanks, your Setup file is much more elegant than our first attempt,
which included everything many, many times.

But we found 1 things that you may want to know about when using it with
Oracle v8.1.6.
We found the following file in rdbms/public instead of rdbms/demo.

     ociextp.h

So, we added rdbms/public to the following line in the Setup file.

    ORACLE_INCLUDES=$(ORACLE_HOME)/rdbms/demo
-I$(ORACLE_HOME)/rdbms/public -I$(ORACLE_HOME)/network/public
-I$(ORACLE_HOME)/plsql/public

Then we can build it and use DCOracle.  I guess we could have moved the
file to demo, but presumably Oracle has reasons for trouncing files
around to different areas in different releases;{

thanks,
Matt Vranicar
Fermilab







From vranicar@fnal.gov  Thu Mar 23 23:30:19 2000
From: vranicar@fnal.gov (Matthew Vranicar)
Date: Thu, 23 Mar 2000 17:30:19 -0600
Subject: [DB-SIG] DCOracle, Oracle 8i LOBs troubles
Message-ID: <38DAA90B.FC65592A@fnal.gov>

We are still having trouble with LOBs.  The doc/DCOracle.txt simply
states
"To get LOB support, you must link against Oracle 8 client
libraries and make sure that the -DDCORACLE8 switch is supplied
when the oci_ extension module is built."

We did this when we built DCOracle v1.3.0 against Oracle v8.0.4 and the
LOB support worked wonderfully.  But, we cannot seem to make it work
with Oracle v8.1.5 nor v8.1.6 and DCOracle v1.3.0.

Here is an interactive python session showing the message we get when
trying to query CLOBs.
The column FILE_PARM_TEXT is a clob.

>>> cur.execute("select FILE_PARM_TEXT from DATA_FILE_PARAMETERS where
DATA_FILE_PARAMETERS.FILE_PARM_ID = 99768")
>>> p = cur.fetchall()
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "DCOracle/ociCurs.py", line 368, in fetchall
  File "DCOracle/ociCurs.py", line 311, in fetchone
  File "DCOracle/ociCurs.py", line 83, in _error
oci.error: (24813, 'ORA-24813: cannot send or receive an unsupported
LOB\012')

>>> cur.execute("select FILE_PARM_TEXT from DATA_FILE_PARAMETERS where
DATA_FILE_PARAMETERS.FILE_PARM_ID = 99768")
>>> p = cur.fetchone()
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "DCOracle/ociCurs.py", line 311, in fetchone
  File "DCOracle/ociCurs.py", line 83, in _error
oci.error: (24813, 'ORA-24813: cannot send or receive an unsupported
LOB\012')

As I said - this worked fine with Oracle 8.0.4.  Any ideas?
thanks,
Matt Vranicar
Fermilab









From sgendler@impossible.com  Thu Mar 23 23:35:37 2000
From: sgendler@impossible.com (Sam Gendler)
Date: Thu, 23 Mar 2000 15:35:37 -0800
Subject: [DB-SIG] One last quick question
References: <38D9E11F.C22EF6DE@impossible.com> <38D9ED92.46102EDA@lemburg.com> <38DA7E7D.E94D08C2@impossible.com> <38DA883A.C939938A@lemburg.com>
Message-ID: <38DAAA49.546CA271@impossible.com>

How does one use the Timestamp() function, that is supposed to be supplied by a dbi
2.0 compliant module, when executing an INSERT query.

I have the (year,month,day,hour,minute,second) tuple, but how do I construct the
INSERT query such that the query gets constructed correctly.

Currently, I am just building a string manually and inserting it into the query
string with the % operator.

--sam



From mal@lemburg.com  Fri Mar 24 08:41:12 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 24 Mar 2000 09:41:12 +0100
Subject: [DB-SIG] One last quick question
References: <38D9E11F.C22EF6DE@impossible.com> <38D9ED92.46102EDA@lemburg.com> <38DA7E7D.E94D08C2@impossible.com> <38DA883A.C939938A@lemburg.com> <38DAAA49.546CA271@impossible.com>
Message-ID: <38DB2A28.5C6F86B9@lemburg.com>

Sam Gendler wrote:
> 
> How does one use the Timestamp() function, that is supposed to be supplied by a dbi
> 2.0 compliant module, when executing an INSERT query.
> 
> I have the (year,month,day,hour,minute,second) tuple, but how do I construct the
> INSERT query such that the query gets constructed correctly.
> 
> Currently, I am just building a string manually and inserting it into the query
> string with the % operator.

Normal usage is via bound parameters, e.g.
c.execute("insert into ... values (?,?,?)",Timestamp(2000,03,24,9,40,0))

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




From m.perkonigg@carinthia-edv.co.at  Mon Mar 27 11:02:13 2000
From: m.perkonigg@carinthia-edv.co.at (Michael Perkonigg)
Date: Mon, 27 Mar 2000 12:02:13 +0100
Subject: [DB-SIG] MySQLdb for AIX
Message-ID: <C12568AF.0036FF9F.00@viecos2.srv.dsh.at>


Hi!

Does anyone have a MySQLdb module already compiled for AIX?
I can't compile it because we don't have a XLC anymore. And build.py (make -f
Makefile.pre.in boot) dies with errors when I use gcc.

Regards,
Mike




From ljoramo.list@nickads.com  Wed Mar 29 15:29:54 2000
From: ljoramo.list@nickads.com (Lee Joramo)
Date: Wed, 29 Mar 2000 08:29:54 -0700
Subject: [DB-SIG] Installing pgsql (PostgreSQL Interface) results in swig errors
Message-ID: <v04210103b507cfb59b52@[192.168.1.2]>

I originally posted this to python-list@python.org because I believe that
it is more of a generic installation problem than a db problem. I didn't
get a response, so I am reposting on db-sig.

-------------------


I am having problems installing pgsql
<http://starship.python.net/crew/cjr/> on Cobalt RAQ3 system. (Essentially,
a modified Redhat installation).

I think that I now have the paths in config.cache correctly setup, but when
I do "make" I get the following results:

------

(cd swigsrc; make; cd ..)
make[1]: Entering directory
`/home/sites/site1/users/ljoramo/temp/pgsql/swigsrc'
swig -python -shadow -I/usr/include/pgsql pgsqldb.i
make[1]: swig: Command not found
make[1]: *** [pgsqldb_module.c] Error 127
make[1]: Leaving directory `/home/sites/site1/users/ljoramo/temp/pgsql/swigsrc'
gcc -fpic  -g -O2 -I/usr/include/python1.5 -I/usr/include/python1.5
-DHAVE_CONFIG_H -c ./pgsqldb_wrap.c
./pgsqldb_wrap.c:320: parse error before `('
make: *** [pgsqldb_wrap.o] Error 1

------

I have looked for information related to "swig" in the various python list
archives and get the feeling that it is a program that I do not have on my
system. But I could find nothing definitive. I have searched by system for
swig and found nothing.

Thanks

--
Lee A. Joramo                      ljoramo@nickads.com
The Nickel Want Ads                www.nickads.com
Internet Manager                   970-242-5555



From ljoramo.list@nickads.com  Wed Mar 29 18:22:38 2000
From: ljoramo.list@nickads.com (Lee Joramo)
Date: Wed, 29 Mar 2000 11:22:38 -0700
Subject: [DB-SIG] Installing pgsql : error on make
Message-ID: <v04210106b507f981716c@[192.168.1.2]>

Still trying to install pgsql. I have gotten "swig" installed, but now I
run into another problem. When I type "make" I get the flowing error:

---

gcc -fpic  -g -O2 -I/usr/include/python1.5 -I/usr/include/python1.5
-DHAVE_CONFIG_H -c ./pgsqldb_wrap.c
./pgsqldb_wrap.c:320: parse error before `('
make: *** [pgsqldb_wrap.o] Error 1

---

Below you will find the contents of the config.cache and the results of the
"make -f Makefile.pre.in boot"

TIA,

--
Lee A. Joramo                      ljoramo@nickads.com
The Nickel Want Ads                www.nickads.com
Internet Manager                   970-242-5555




-- Contents of config.cache -----------------------------------

ac_cv_path_PYTHON=${ac_cv_path_PYTHON='/usr/bin/python'}
py_cv_python_exec_prefix=${py_cv_python_exec_prefix='/usr'}
py_cv_python_makefile_CC=${py_cv_python_makefile_CC='gcc'}
py_cv_python_makefile_CCSHARED=${py_cv_python_makefile_CCSHARED='-fpic'}
py_cv_python_makefile_DEFS=${py_cv_python_makefile_DEFS='-DHAVE_CONFIG_H'}
py_cv_python_makefile_EXEC_PREFIX=${py_cv_python_makefile_EXEC_PREFIX='${pre
fix}'}
py_cv_python_makefile_LDFLAGS=${py_cv_python_makefile_LDFLAGS=''}
py_cv_python_makefile_LDSHARED=${py_cv_python_makefile_LDSHARED='gcc -shared'}
py_cv_python_makefile_LIBC=${py_cv_python_makefile_LIBC=''}
py_cv_python_makefile_LIBM=${py_cv_python_makefile_LIBM='-lm'}
py_cv_python_makefile_LIBS=${py_cv_python_makefile_LIBS='-lieee -ldl
-lpthread'}
py_cv_python_makefile_LINKFORSHARED=${py_cv_python_makefile_LINKFORSHARED='-
Xlinker -export-dynamic'}
py_cv_python_makefile_MACHDEP=${py_cv_python_makefile_MACHDEP='linux2'}
py_cv_python_makefile_OPT=${py_cv_python_makefile_OPT='-g -O2'}
py_cv_python_makefile_PREFIX=${py_cv_python_makefile_PREFIX='/usr/lib/python
1.5/config'}
py_cv_python_makefile_RANLIB=${py_cv_python_makefile_RANLIB='ranlib'}
py_cv_python_makefile_SO=${py_cv_python_makefile_SO='.so'}
py_cv_python_makefile_vars=${py_cv_python_makefile_vars='found'}
py_cv_python_prefix=${py_cv_python_prefix='/usr'}
py_cv_python_version=${py_cv_python_version='1.5'}

-- End Contents of config.cache -----------------------------------



[ljoramo@server1 pgsql]$ make -f Makefile.pre.in boot

rm -f *.o *~ *.so
rm -f *.pyc
rm -f *.a tags TAGS config.c Makefile.pre python sedscript
rm -f *.so *.sl so_locations
VERSION=`python -c "import sys; print sys.version[:3]"`; \
installdir=`python -c "import sys; print sys.prefix"`; \
exec_installdir=`python -c "import sys; print sys.exec_prefix"`; \
make -f ./Makefile.pre.in VPATH=. srcdir=. \
        VERSION=$VERSION \
        installdir=$installdir \
        exec_installdir=$exec_installdir \
        Makefile
make[1]: Entering directory `/home/sites/site1/users/ljoramo/temp/pgsql/pgsql'
sed -n \
 -e '1s/.*/1i\\/p' \
 -e '2s%.*%# Generated automatically from Makefile.pre.in by sedscript.%p' \
 -e '/^VERSION=/s/^VERSION=[    ]*\(.*\)/s%@VERSION[@]%\1%/p' \
 -e '/^CC=/s/^CC=[      ]*\(.*\)/s%@CC[@]%\1%/p' \
 -e '/^CCC=/s/^CCC=[    ]*\(.*\)/s%#@SET_CCC[@]%CCC=\1%/p' \
 -e '/^LINKCC=/s/^LINKCC=[      ]*\(.*\)/s%@LINKCC[@]%\1%/p' \
 -e '/^OPT=/s/^OPT=[    ]*\(.*\)/s%@OPT[@]%\1%/p' \
 -e '/^LDFLAGS=/s/^LDFLAGS=[    ]*\(.*\)/s%@LDFLAGS[@]%\1%/p' \
 -e '/^DEFS=/s/^DEFS=[  ]*\(.*\)/s%@DEFS[@]%\1%/p' \
 -e '/^LIBS=/s/^LIBS=[  ]*\(.*\)/s%@LIBS[@]%\1%/p' \
 -e '/^LIBM=/s/^LIBM=[  ]*\(.*\)/s%@LIBM[@]%\1%/p' \
 -e '/^LIBC=/s/^LIBC=[  ]*\(.*\)/s%@LIBC[@]%\1%/p' \
 -e '/^RANLIB=/s/^RANLIB=[      ]*\(.*\)/s%@RANLIB[@]%\1%/p' \
 -e '/^MACHDEP=/s/^MACHDEP=[    ]*\(.*\)/s%@MACHDEP[@]%\1%/p' \
 -e '/^SO=/s/^SO=[      ]*\(.*\)/s%@SO[@]%\1%/p' \
 -e '/^LDSHARED=/s/^LDSHARED=[  ]*\(.*\)/s%@LDSHARED[@]%\1%/p' \
 -e '/^CCSHARED=/s/^CCSHARED=[  ]*\(.*\)/s%@CCSHARED[@]%\1%/p' \
 -e '/^LINKFORSHARED=/s/^LINKFORSHARED=[
]*\(.*\)/s%@LINKFORSHARED[@]%\1%/p' \
 -e '/^prefix=/s/^prefix=\(.*\)/s%^prefix=.*%prefix=\1%/p' \
 -e
'/^exec_prefix=/s/^exec_prefix=\(.*\)/s%^exec_prefix=.*%exec_prefix=\1%/p' \
 /usr/lib/python1.5/config/Makefile >sedscript
echo "/^#@SET_CCC@/d" >>sedscript
echo "/^installdir=/s%=.*%=     /usr%" >>sedscript
echo "/^exec_installdir=/s%=.*%=/usr%" >>sedscript
echo "/^srcdir=/s%=.*%=         .%" >>sedscript
echo "/^VPATH=/s%=.*%=          .%" >>sedscript
echo "/^LINKPATH=/s%=.*%=       %" >>sedscript
echo "/^BASELIB=/s%=.*%=        %" >>sedscript
echo "/^BASESETUP=/s%=.*%=      %" >>sedscript
sed -f sedscript ./Makefile.pre.in >Makefile.pre
/usr/lib/python1.5/config/makesetup \
         -m Makefile.pre -c /usr/lib/python1.5/config/config.c.in Setup -n
/usr/lib/python1.5/config/Setup
make -f Makefile do-it-again
make[2]: Entering directory `/home/sites/site1/users/ljoramo/temp/pgsql/pgsql'
/usr/lib/python1.5/config/makesetup \
         -m Makefile.pre -c /usr/lib/python1.5/config/config.c.in Setup -n
/usr/lib/python1.5/config/Setup
make[2]: Leaving directory `/home/sites/site1/users/ljoramo/temp/pgsql/pgsql'
make[1]: Leaving directory `/home/sites/site1/users/ljoramo/temp/pgsql/pgsql'

[ljoramo@server1 pgsql]$ make

gcc -fpic  -g -O2 -I/usr/include/python1.5 -I/usr/include/python1.5
-DHAVE_CONFIG_H -c ./pgsqldb_wrap.c
./pgsqldb_wrap.c:320: parse error before `('
make: *** [pgsqldb_wrap.o] Error 1
--

Onward and Upward!

Lee A. Joramo }}-----> Cowboy on the Electronic Frontier

lee@joramo.com

Alamar Ranch  -  Palisade  -  Colorado

ThreeRivers|Eagle|UCD|D&D|TNC|DX|Mac|221B|Cannondale|Deutsch