From rstacy@variagenics.com Thu Apr 2 21:43:54 1998 From: rstacy@variagenics.com (Rick Stacy) Date: Thu, 02 Apr 1998 16:43:54 -0500 Subject: [DB-SIG] Oracle 8.0.3 & Python 1.5 Message-ID: <3524069A.41C6@variagenics.com> Hi, Is anyone out there using the Oracle module (0.1.3) from Digicool with Python 1.5 and Oracle 8.0.3 on the SGI IRIX 6.4 platform? I've been having a heck of a time trying to determine the proper list of libraries to include in the makefile. If anyone has already dealt with this issue and is willing to pass along the solution, it would be greatly appreciated. Thanks in advance -- Rick Stacy | Senior Scientist, Bioinformatics | I didn't claw my way to the top of Variagenics, Inc. | the food chain to eat veggies! rstacy@variagenics.com | From pgodman@halcyon.com Sat Apr 4 05:36:59 1998 From: pgodman@halcyon.com (Peter Godman) Date: Fri, 3 Apr 1998 21:36:59 -0800 (PST) Subject: [DB-SIG] Painful realization / cry for help Message-ID: About 9 months ago I read an email about possibly closing the db-sig. Soon afterwards I stopped receiving email from db-sig. For these nine months I thought the sig had closed down. Consequently I announced the availability of a dbapi sybase module to the main list only. I don't know why my subscription ended. I may have even ended it myself, thinking the sig was no more. Anyway, it's good to be back, especially now that I am actually going to be doing some work with dbapi (though not sybase). Which brings me to my second point. I'm sadly in the position of not really being able to maintain the sybase module right now. This is because I don't have access to a sybase server. If anyone could help with this, perhaps by making an empty database (not necessarily a server) available over the net, I would appreciate it. If I can't resolve this issue soon, I will be forced to relinquish maintenace of the module. Already, I have several backlogged patches (thanks to all who have provided them (I haven't forgotten)). Well, glad to see the SIG is alive and well. Peter Godman From mal@lemburg.com Sat Apr 4 15:19:04 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 04 Apr 1998 17:19:04 +0200 Subject: [DB-SIG] ANN: mxODBC v0.7 and mxDateTime v0.8 Message-ID: <35264F68.549443A6@lemburg.com> After a few weeks of silence there are new versions of my two extension packages. mxODBC is a nearly 100% DB-API compliant interface to the ODBC 2.0 API. mxDateTime fixes the problems you face when dealing with date and time values (e.g. ones before 1.1.1970). The ODBC package uses the DateTime package for its default date/time handling (other formats supported are: Unix ticks, string representations and tuple style, e.g. (year,month,day)). For further information have a look at the documentation (which also provides the links to the archives): http://starship.skyport.net/~lemburg/mxODBC.html http://starship.skyport.net/~lemburg/mxDateTime.html The DateTime package is now stabilizing. Version 1.0 will hopefully be the "final" release. Please try it and report any bugs you find, so that I can fix them until 1.0 comes out. Here is the list of changes: mxODBC: Changes from 0.6 to 0.7: Documented cursor.datetimeformat. Synchronized the module with my mxDateTime extension package. Updated the dbi.py abstraction module. It is still not 100% compatible with what the API 1.0 specs say (the module does not return instances of dbiRaw and dbiDate), but I'm reluctant to fix it. Added a cleanup function that get's called when the interpreter finalizes. It deallocates the ODBC environment. Added __members__ attribute to cursors. This returns a list of known attributes (e.g. dir() looks for it and displays them). Added optional fourth parameter clear_auto_commit to the connection constructor. Date, time and timestamp can now also be processed via Python strings. The conversion is left to the ODBC driver/manager. Fixed a bug in the allocation routines of both the connection and the cursor type that sometimes caused a segfault due to an ODBC error occurring while connecting. Added a new API DriverConnect and renamed the old API Connect. The old one is still aliased to ODBC for DB API compliance and backward compatibility. Fixed a refcount bug that prevented connection objects from begin garbage collected after a cursor was used on them (the cursor didn't dereference the connection object). mxDateTime: Things that changed from 0.7 to 0.8: Important change: Conversions from and to Unix time values (ticks) are now done assuming the broken down values represent local time, not UTC as in previous versions. now() returns local time instead of UTC -- this was confusing to some users. The change had to be done since I didn't want to carry the timemodule.c stuff all along the way... the method I used to convert from mktime() output to UTC was flaky anyway. Important for programmers wanting to use the C interface: I dropped the direct access macros in the mxDateTime header file. If you want to access the broken down representation of the instances from C, use the new DateTime[Delta]_BrokenDown() APIs. I did this, because I may decide to put the two types on a diet in a next version (i.e. dropping the cached broken down values). Added an alias 'Format' for the method DateTime.strftime. This makes the DateTime type compatible with the existing PythonWin date type. DateTime.strftime() defaults to '%c' as format string if no parameters are given. Dropped the plan to add keywords handling: it would produce a noticable performance hit due to the way keyword handling works in the interpreter. Dropped the module specific ConversionError in favour of the standard OverflowError. Conversion to ticks will raise an OverflowError in case the converted value doesn't fit into the machines time value format. Moved some constructors and objects from mxDateTime to DateTime. You won't notice any difference if you are using the DateTime interface (which you should), except the fact that some functions are now coded in Python rather than C. The TimeDelta() constructor now accepts keywords. This is a side-effect from moving it out of the C module into the Python package module. You can now write twoMinutes = TimeDelta(minutes=2). Added an experimental ODMG submodule that uses date/time classes built on top of the two basic types. The main difference is that they support timezone offsets. Added support for storing COM dates as-is. DateTimeFromCOMDate(x).COMDate() will always return x unchanged. -- Marc-Andre Lemburg ...................................................................... | Python Pages: http://starship.skyport.net/~lemburg/ | -------------------------------------------------------- From hpa@trema.com Tue Apr 14 10:45:46 1998 From: hpa@trema.com (Harri Pasanen) Date: Tue, 14 Apr 1998 11:45:46 +0200 Subject: [DB-SIG] Sybase module, DB-api description attribute Message-ID: <3533304A.D2A3FBDE@trema.com> Hi, What is the current status of Sybase module development? I've been testing Peter Godman's ctsybase module on SunOS 5.6 with Python 1.5, and my preliminary tests seem to have it functioning ok. But how is the description attribute supposed to be populated? The current ctsybase module seems to fill it mainly with raw return values of Sybase, so the column description tuples look something like ('name', 0, 0, 255, 0, 0, 0) Has there been any talk about getting more detailed meta data out of databases, for instance where the DBI object types would be a union of all supported database types? Thanks, Harri From raf@comdyn.com.au Tue Apr 14 10:47:24 1998 From: raf@comdyn.com.au (raf) Date: Tue, 14 Apr 1998 19:47:24 +1000 Subject: [DB-SIG] Painful realization / cry for help Message-ID: <199804140947.TAA09458@mali.comdyn.com.au> Peter Godman wrote: >Which brings me to my second point. I'm sadly in the position of not >really being able to maintain the sybase module right now. This is >because I don't have access to a sybase server. If anyone could help with >this, perhaps by making an empty database (not necessarily a server) >available over the net, I would appreciate it. If I can't resolve this >issue soon, I will be forced to relinquish maintenace of the module. >Already, I have several backlogged patches (thanks to all who have >provided them (I haven't forgotten)). i can't provide a sybase server online for you but i do have plenty of access to sybase :| so for the time being i can maintain the module if that's what you want. raf From pgodman@halcyon.com Tue Apr 14 19:02:39 1998 From: pgodman@halcyon.com (Peter Godman) Date: Tue, 14 Apr 1998 11:02:39 -0700 (PDT) Subject: [DB-SIG] Sybase module, DB-api description attribute In-Reply-To: <3533304A.D2A3FBDE@trema.com> Message-ID: On Tue, 14 Apr 1998, Harri Pasanen wrote: > Hi, > > What is the current status of Sybase module development? > I sent an email a few days ago stating the current status of module development for me... not much, pending access to a Sybase database. I'm working on getting access, though. > I've been testing Peter Godman's ctsybase module on SunOS 5.6 with > Python 1.5, and my > preliminary tests seem to have it functioning ok. > > But how is the description attribute supposed to be populated? The > current ctsybase module > seems to fill it mainly with raw return values of Sybase, so the column > description tuples look something > like ('name', 0, 0, 255, 0, 0, 0) Well, I tried to do what the spec said, with some amount of trepidation, given the closing disclaimer. description This read-only attribute is a tuple of 7-tuples. /* I did a list of 7-tuples */ Each 7-tuple contains information describing each result column: (name, type_code, display_size, internal_size, precision, scale, null_ok). This attribute will be None for operations that do not return rows or if the cursor has not had an operation invoked via the execute() method yet. The type_code is one of the dbi values specified in the section below. Note: this is a bit in flux. Generally, the first two items of the 7-tuple will always be present; the others may be database specific. However, there is no available display length, and the data type is returned, as you suspected, as a sybase constant. I should add these constants to the module. I will be able to do something a little more elegant when I add dbi types. > > Has there been any talk about getting more detailed meta data out of > databases, for instance where > the DBI object types would be a union of all supported database types? > I think this is a good idea. However, I think people are still going to want to deal with native types where possible. Furthermore, the range of types supported by a database varies widely, making a union messy, and may not even be known upon installation (user may install her own complex types). > > Thanks, > > Harri > Thanks, Pete > > ------------------------------------------------------ > DB-SIG maillist - DB-SIG@python.org > http://www.python.org/mailman/listinfo/db-sig > From quentin@s1.com Wed Apr 15 19:54:55 1998 From: quentin@s1.com (Quentin Neill) Date: Wed, 15 Apr 1998 14:54:55 -0400 Subject: [DB-SIG] Symbol conflict? Message-ID: <199804151854.OAA31737@spike.s-1.com> I was building Python1.5 on an HP 10.20 system with Informix 7.24 installed, and I ran into a multiply defined symbol "initsocket" 1. initsocket defined in Modules/socketmodule.c 2. initsocket defined in libixasf, libtasf, libasf, netlib Has anyone else seen this? How did you workaround? Our workaround was to patch the Modules/socketmodule.c and Modules/config.c files after configuration to avoid the collision. Seems the "right" way to fix this is a name change in the python module interfaces, perhaps a "py_" prefix for all the modules. -- Thanks, Quentin Neill qneill@s-1.com 404-812-6658 Security First Technologies Support your favorite non-profit organization: http://www.eyegive.com/html/ssi.cfm?MID=5214 From Tod Olson Thu Apr 16 21:12:10 1998 From: Tod Olson (Tod Olson) Date: Thu, 16 Apr 1998 15:12:10 -0500 Subject: [DB-SIG] Painful realization / cry for help In-Reply-To: Your message of "Fri, 3 Apr 1998 21:36:59 -0800 (PST)" References: Message-ID: <199804162012.PAA24437@stone.lib.uchicago.edu> >>>>> "PG" == Peter Godman writes: PG> Which brings me to my second point. I'm sadly in the position of not PG> really being able to maintain the sybase module right now. This is PG> because I don't have access to a sybase server. If anyone could help PG> with this, perhaps by making an empty database (not necessarily a PG> server) available over the net, I would appreciate it. If I can't PG> resolve this issue soon, I will be forced to relinquish maintenace of PG> the module. Already, I have several backlogged patches (thanks to all PG> who have provided them (I haven't forgotten)). I'm not at all happy to hear that. I was hoping that you and I would be able to pool our Sybase module efforts, since we each have features in our modules that the other's lacks. And I'll actually be able to return to working on my Sybase module, one we hire a couple people. [Solicitation for job applicants follows] Speaking of which, we're looking for two Unix programmer / sysadmin types: These are new positions. Postings are at: http://www2.uchicago.edu/adm-uhrm/jobpost/out/p98-379.html http://www2.uchicago.edu/adm-uhrm/jobpost/out/p98-340.html These are, of course, in Chicago and academic wage. If anyone's interested, talk to me. Tod A. Olson "How do you know I'm mad?" said Alice. ta-olson@uchicago.edu "If you weren't mad, you wouldn't have The University of Chicago Library come here," said the Cat. From john@nmt.edu Thu Apr 16 23:37:30 1998 From: john@nmt.edu (John W. Shipman) Date: Thu, 16 Apr 1998 16:37:30 -0600 (MDT) Subject: [DB-SIG] Painful realization / cry for help In-Reply-To: <199804162012.PAA24437@stone.lib.uchicago.edu> Message-ID: +-- Tod A. Olson (ta-olson@uchicago.edu): | I'm not at all happy to hear that [Peter Godman has no access | to Sybase]. I was hoping that you and I would be able to pool | our Sybase module efforts, since we each have features in our | modules that the other's lacks. And I'll actually be able to | return to working on my Sybase module, one we hire a couple | people. +-- I work for a college computer center, and we plan to build a bunch of applications in Python using Peter's module, so we'd like to help out. I'm not sure if we can get him an account here, but at the very least I could test things for him. I'm also interested in working on any new development efforts for the Python-Sybase interface. I'm a veteran developer and would like to use Cleanroom methodology to ensure that the code is as bug-free as possible; for more information on Cleanroom, see . (I'm not looking for a job, but volunteering to work on this as part of my current job.) Best regards, John Shipman (john@nmt.edu), Applications Specialist, NM Tech Computer Center, Speare 19, Socorro, NM 87801, (505) 835-5950, http://www.nmt.edu/~john ``Let's go outside and commiserate with nature.'' --Dave Farber From harri.pasanen@trema.com Fri Apr 17 15:53:07 1998 From: harri.pasanen@trema.com (Harri PASANEN) Date: Fri, 17 Apr 1998 16:53:07 +0200 Subject: [DB-SIG] A small bugfix for sybase module References: Message-ID: <35376CD3.D878292C@trema.com> ctsybasemodule.c In line 31, where it fills up the description structure, some parenthesis are in order. After the fix the line looks like: ((fmt+i)->status & CS_CANBENULL) != 0); /* nulls ok */ In the current release it is like (fmt+i)->status & CS_CANBENULL != 0); /* nulls ok */ Without the parenthesis at least gcc 2.8.1 on Sparc-Solaris it seems as if it is folding the constant CS_CANBENULL != 0 to 1 which then matches the wrong status bit. Harri From pgodman@halcyon.com Fri Apr 17 19:27:30 1998 From: pgodman@halcyon.com (Peter Godman) Date: Fri, 17 Apr 1998 11:27:30 -0700 (PDT) Subject: [DB-SIG] Re: A small bugfix for sybase module In-Reply-To: <35376CD3.D878292C@trema.com> Message-ID: On Fri, 17 Apr 1998, Harri PASANEN wrote: > ctsybasemodule.c > > In line 31, where it fills up the description structure, some parenthesis are > in order. After the fix the line looks like: > > ((fmt+i)->status & CS_CANBENULL) != 0); /* nulls ok */ > > > In the current release it is like > > (fmt+i)->status & CS_CANBENULL != 0); /* nulls ok */ > > Without the parenthesis at least gcc 2.8.1 on Sparc-Solaris it seems as if it > is folding the constant CS_CANBENULL != 0 to 1 which then matches > the wrong status bit. > > > Harri Strangely, I just noticed the same line yesterday, and thought it looked odd. However, I didn't know != binds tighter (shame). Thanks for the patch. Pete From dieter@sz-sb.de Thu Apr 23 08:39:09 1998 From: dieter@sz-sb.de (Dr. Dieter Maurer) Date: Thu, 23 Apr 1998 09:39:09 +0200 Subject: [DB-SIG] Positioned Update/Delete Message-ID: <199804230739.JAA20464@dieter.sz-sb.de> How should positioned update/delete be best used with the DB-API: 1. cursor.execute("update set ... where CURRENT") 2. cursor.execute("update set ... where CURRENT of SELF") 3. cursor.execute("update set ... where CURRENT of %s" % str(cursor)) 4. cursor.execute("update set ... where CURRENT of ?",(cursor,)) or 5. cursor.update("set ...") i.e. with a new method. Best regards Dieter From adustman@comstar.net Thu Apr 23 14:26:41 1998 From: adustman@comstar.net (adustman@comstar.net) Date: Thu, 23 Apr 1998 09:26:41 -0400 (EDT) Subject: [DB-SIG] Positioned Update/Delete In-Reply-To: <199804230739.JAA20464@dieter.sz-sb.de> Message-ID: On Thu, 23 Apr 1998, Dr. Dieter Maurer wrote: > How should positioned update/delete be best used with the DB-API: > > 1. cursor.execute("update set ... where CURRENT") > 2. cursor.execute("update set ... where CURRENT of SELF") > 3. cursor.execute("update set ... where CURRENT of %s" % str(cursor)) > 4. cursor.execute("update set ... where CURRENT of ?",(cursor,)) 4a. cursor.execute("update TABLE set CURRENT = ?", (current,)) Assuming you are using an SQL-89 or so database; the API doesn't really specify the query language syntax. -- Andy Dustman WW Charles Babbage: ComStar Communications Corp. BB He never used Linux, (770) 333-8779 | PGP KeyID=0xC72F3F1D D? and now, he's dead. From dieter@sz-sb.de Thu Apr 23 14:47:50 1998 From: dieter@sz-sb.de (Dr. Dieter Maurer) Date: Thu, 23 Apr 1998 15:47:50 +0200 Subject: [DB-SIG] Positioned Update/Delete In-Reply-To: References: <199804230739.JAA20464@dieter.sz-sb.de> Message-ID: <199804231347.PAA21632@dieter.sz-sb.de> Dear Andy Thank you for your reply. > On Thu, 23 Apr 1998, Dr. Dieter Maurer wrote: > > How should positioned update/delete be best used with the DB-API: <----- snip ----> > > > 4a. cursor.execute("update TABLE set CURRENT = ?", (current,)) > > Assuming you are using an SQL-89 or so database; the API doesn't really > specify the query language syntax. I know. SQL-92 specifies: positioned-update::= UPDATE [table] SET update-assignment-commalist WHERE CURRENT OF cursor Thus, I could formulate my question better in this way: "How should the cursor (which is a Python object) best be transported into the SQL world." I see two interpretations for your suggestion: 1. you suggest not to specify it at all (and "current" (in your suggestion) means the new value). But this might conflict with a searched update where the "where" clause has been omitted. 2. "current" (in your suggestion) means in fact "cursor" which should be transfered via dynamic parameter into the SQL world. I can imagine, that this is a good solution. Thank you again. Dieter From adustman@comstar.net Thu Apr 23 15:10:13 1998 From: adustman@comstar.net (adustman@comstar.net) Date: Thu, 23 Apr 1998 10:10:13 -0400 (EDT) Subject: [DB-SIG] Positioned Update/Delete In-Reply-To: <199804231347.PAA21632@dieter.sz-sb.de> Message-ID: On Thu, 23 Apr 1998, Dr. Dieter Maurer wrote: > > On Thu, 23 Apr 1998, Dr. Dieter Maurer wrote: > > > How should positioned update/delete be best used with the DB-API: > <----- snip ----> > > > > > 4a. cursor.execute("update TABLE set CURRENT = ?", (current,)) > > > > Assuming you are using an SQL-89 or so database; the API doesn't really > > specify the query language syntax. > I know. > SQL-92 specifies: > positioned-update::= > UPDATE [table] > SET update-assignment-commalist > WHERE CURRENT OF cursor > > Thus, I could formulate my question better in this way: > "How should the cursor (which is a Python object) best be transported > into the SQL world." > > I see two interpretations for your suggestion: > 1. you suggest not to specify it at all (and "current" (in your suggestion) > means the new value). But this might conflict with a searched > update where the "where" clause has been omitted. I was assuming what you wanted here was to update the column CURRENT (I wasn't aware of the use of CURRENT as a reserved word). If there is a is a where clause, you would need something like this: cursor.execute("""UPDATE mytable SET Value1 = ?, Value2 = ?, Value3 = ? WHERE Index = ?""", (v1, v2, v3, i)) Values are substituted in the order they appear. You don't need to specify the cursor in the SQL statement. You are effectively telling the cursor to execute the SQL statement. -- Andy Dustman WW Charles Babbage: ComStar Communications Corp. BB He never used Linux, (770) 333-8779 | PGP KeyID=0xC72F3F1D D? and now, he's dead. From pgodman@halcyon.com Thu Apr 23 17:08:54 1998 From: pgodman@halcyon.com (Peter Godman) Date: Thu, 23 Apr 1998 09:08:54 -0700 (PDT) Subject: [DB-SIG] Positioned Update/Delete In-Reply-To: Message-ID: On Thu, 23 Apr 1998 adustman@comstar.net wrote: > On Thu, 23 Apr 1998, Dr. Dieter Maurer wrote: > > > How should positioned update/delete be best used with the DB-API: > > > > 1. cursor.execute("update set ... where CURRENT") > > 2. cursor.execute("update set ... where CURRENT of SELF") > > 3. cursor.execute("update set ... where CURRENT of %s" % str(cursor)) > > 4. cursor.execute("update set ... where CURRENT of ?",(cursor,)) > > 4a. cursor.execute("update TABLE set CURRENT = ?", (current,)) > > Assuming you are using an SQL-89 or so database; the API doesn't really > specify the query language syntax. > Just as a note of interest, Sybase's client library (ct) supports client-side cursors, which means that I will have to superset DBAPI a little to support them. I think it will be just a matter of adding update and delete methods to the cursor type. Do any of the other APIs support client-side cursors? In Sybase parlance, the above discussion would be about "Language cursors". So I guess there will be 5. cursor.update("set ...") and cursor.delete() for Sybase. What do people feel about making this feature a part of basic DBAPI? Peter Godman From johnl@axis.com.au Thu Apr 30 07:49:57 1998 From: johnl@axis.com.au (John Lehmann) Date: Thu, 30 Apr 1998 16:49:57 +1000 Subject: [DB-SIG] Support for Illustra-python? Message-ID: <35481F15.CDEA9775@axis.com.au> Hello, I noticed some mention of support for Illustra on the findmail archive for this list, but can't find an illustra module (only informix... which I did try to compile :) Is there an illustra module anywhere? -- | John J. Lehmann, johnl@axis.com.au + >>>>20. You start tilting your head sideways to smile. From mcclure@s1.com Thu Apr 30 23:12:05 1998 From: mcclure@s1.com (Steve McClure) Date: Thu, 30 Apr 1998 18:12:05 -0400 Subject: [DB-SIG] Question about DBI data types Message-ID: <199804302212.SAA27975@eskimo.s-1.com> I am using the informixdb module and found that floating point data is being passed back to my Python script truncated to an integer value. After a little code tracing I found that the informixdb implementation is at fault. Now I would like to fix it but the DBI specification is a little vague on what the data should look like. I thought that perhaps the size, precision or scale elements of the description tuple should be used to describe the data. Are there any standards in place for handling this? Defacto perhaps because some module has implemented it? Thanks for any direction or help, Steve -- Steve.McClure@S1.com Voice 404-812-6613 Security First Technologies Fax 404-812-6616 3390 Peachtree Road, Suite 1700 http://www.sfnb.com Atlanta, GA 30326-1108 http://www.s1.com