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 Wed Mar 8 18:21:21 2000 From: Garrett Gradisar (Garrett Gradisar) Date: Wed, 8 Mar 2000 11:21:21 -0700 (MST) Subject: [DB-SIG] a little help please Message-ID: #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: 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 License: Python-style

MySQLdb 0.1.3 - 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: Message-ID: 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: from Garrett Gradisar at "Mar 8, 2000 11:21:21 am" Message-ID: 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 | 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: 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: 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: 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: 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: ; from adustman@comstar.net on Thu, Mar 09, 2000 at 02:46:49PM -0500 References: <38C7E7B9.ADD83BFA@lemburg.com> 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> <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: 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: 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: 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: Message-ID: 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: 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: 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 | 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: 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: 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: <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: 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 "", 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 "", 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: 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: 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 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: 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