From johnm@magnet.com Fri May 1 17:43:08 1998 From: johnm@magnet.com (John Mitchell) Date: Fri, 1 May 1998 12:43:08 -0400 (EDT) Subject: [DB-SIG] Question about DBI data types In-Reply-To: <199804302212.SAA27975@eskimo.s-1.com> Message-ID: On Thu, 30 Apr 1998, Steve McClure wrote: > 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. The informixdb module just sucks. The Date types dont work well -- I had to use " select column||'' " because a direct Select would just return a date from 1970! Anyone have a better version? Replacement? - j From Paul Boddie Fri May 1 18:13:39 1998 From: Paul Boddie (Paul Boddie) Date: Fri, 1 May 1998 19:13:39 +0200 (MET DST) Subject: [DB-SIG] Common Database Module Implementation? Message-ID: <199805011713.TAA14034@aisws7.cern.ch> It occurred to me that, given the stated deficiencies of certain database modules, and the non-uniformity of support that the modules provide for certain DB-API features, to ask whether any thought has been made on a common, basic module implementation which might be customised for each vendor's database. I know that ODBC support is available, but for those of us who value the "native" modules, I wondered whether customised versions of a reference implementation might provide wider, better support of most DB-API features across most database platforms. Unfortunately I only have basic knowledge of Oracle Call Interface, and no knowledge about how other database systems may be called in a similar way, but might it be the case that there are several common parts to each database module implementation, such as the data structures required to hold retrieved row information, and the data structures required to represent certain database types? Has anyone tried to modify one database module to work with another database system? Paul Boddie Paul.Boddie@cern.ch | http://assuwww.cern.ch/~pboddie | Any views expressed above are personal and not necessarily | shared by my employer or my associates. From mal@lemburg.com Sat May 2 10:44:30 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 02 May 1998 11:44:30 +0200 Subject: [DB-SIG] Common Database Module Implementation? References: <199805011713.TAA14034@aisws7.cern.ch> Message-ID: <354AEAFE.49FAB4A9@lemburg.com> Paul Boddie wrote: > > It occurred to me that, given the stated deficiencies of certain database > modules, and the non-uniformity of support that the modules provide for certain > DB-API features, to ask whether any thought has been made on a common, basic > module implementation which might be customised for each vendor's database. I > know that ODBC support is available, but for those of us who value the "native" > modules, I wondered whether customised versions of a reference implementation > might provide wider, better support of most DB-API features across most database > platforms. > > Unfortunately I only have basic knowledge of Oracle Call Interface, and no > knowledge about how other database systems may be called in a similar way, but > might it be the case that there are several common parts to each database module > implementation, such as the data structures required to hold retrieved row > information, and the data structures required to represent certain database > types? Has anyone tried to modify one database module to work with another > database system? I don't think that the native APIs have much in common and seen from the cross-database portability ODBC is pretty hard to beat, IMHO. But, I'm biased :-) What one might try is implementing a different technique of accessing databases altogether: a class based view of things, where tables become objects and queries are built from sets of select-objects, join-objects, etc. These would enable a much cleaner (though less rich) interface to all sorts of databases - even non-SQL ones. -- Marc-Andre Lemburg ...................................................................... | Python Pages: http://starship.skyport.net/~lemburg/ | -------------------------------------------------------- From mal@lemburg.com Sat May 2 10:49:26 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 02 May 1998 11:49:26 +0200 Subject: [DB-SIG] Question about DBI data types References: Message-ID: <354AEC26.2B6F9417@lemburg.com> John Mitchell wrote: > > On Thu, 30 Apr 1998, Steve McClure wrote: > > > 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. > > The informixdb module just sucks. The Date types dont work well -- I had > to use " select column||'' " because a direct Select would just return a > date from 1970! > > Anyone have a better version? Replacement? Doesn't Informix provide an ODBC API ? You could use one of the three ODBC implementations then (PythonWin's odbc, Michael Lausch's soliddb, or my mxODBC). -- Marc-Andre Lemburg ...................................................................... | Python Pages: http://starship.skyport.net/~lemburg/ | -------------------------------------------------------- From adustman@comstar.net Sun May 3 16:08:26 1998 From: adustman@comstar.net (adustman@comstar.net) Date: Sun, 3 May 1998 11:08:26 -0400 (EDT) Subject: [DB-SIG] mxODBC with Solid In-Reply-To: <354AEC26.2B6F9417@lemburg.com> Message-ID: On Sat, 2 May 1998, M.-A. Lemburg wrote: > Doesn't Informix provide an ODBC API ? You could use one of the > three ODBC implementations then (PythonWin's odbc, Michael Lausch's > soliddb, or my mxODBC). Is anyone out there actually using mxODBC with Solid? I gave it a try but there were a number of unresolved symbols due to certain features not being present in Solid's ODBC interface. I could have probably hacked out those features (or added some dummy functions), but at the time, I didn't have time. I was already using the GAMS/Lausch database, which has some probmlems (some of which I think I corrected to make it reliable for my applications). This was a couple months ago, so perhaps the latest version of mxODBC is more directly compatible with Solid (2.2). -- 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 mal@lemburg.com Sun May 3 17:44:07 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 03 May 1998 18:44:07 +0200 Subject: [DB-SIG] Update: mxDateTime Package 0.8.2 Message-ID: <354C9ED7.48D84E56@lemburg.com> You can find the updated package on my Python Pages (see below for the URL). The update includes some minor bug and portability fixes. The next release will be 0.9 -- the final beta. Please try it and report any bugs you find. Additional suggestions are also most welcome. The C API is now frozen and should be easily usable for other database modules as well. If you need examples on how to work with the API, see mxODBC and the included header file mxDateTime.h. -- Cheers, Marc-Andre Lemburg ...................................................................... | Python Pages: http://starship.skyport.net/~lemburg/ | -------------------------------------------------------- From mal@lemburg.com Sun May 3 18:13:57 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 03 May 1998 19:13:57 +0200 Subject: [DB-SIG] mxODBC with Solid References: Message-ID: <354CA5D5.2914A466@lemburg.com> adustman wrote: > > On Sat, 2 May 1998, M.-A. Lemburg wrote: > > > Doesn't Informix provide an ODBC API ? You could use one of the > > three ODBC implementations then (PythonWin's odbc, Michael Lausch's > > soliddb, or my mxODBC). > > Is anyone out there actually using mxODBC with Solid? I gave it a try but > there were a number of unresolved symbols due to certain features not > being present in Solid's ODBC interface. I could have probably hacked out > those features (or added some dummy functions), but at the time, I didn't > have time. I was already using the GAMS/Lausch database, which has some > probmlems (some of which I think I corrected to make it reliable for my > applications). This was a couple months ago, so perhaps the latest version > of mxODBC is more directly compatible with Solid (2.2). Could you be more specific about those unresolved symbols ? I can't remember having used anything that Solid does not implement (after all, I've used their ODBC documentation most of the time). -- Marc-Andre Lemburg ...................................................................... | Python Pages: http://starship.skyport.net/~lemburg/ | -------------------------------------------------------- From arb@connect.com.au Tue May 5 06:51:54 1998 From: arb@connect.com.au (Anthony Baxter) Date: Tue, 05 May 1998 15:51:54 +1000 Subject: [DB-SIG] ODBC with Oracle on Solaris. Message-ID: <199805050551.PAA03390@jambu.off.connect.com.au> Anyone know what bits are needed to use ODBC on Solaris, with Oracle? Our DBA here only knows of win95/NT ODBC drivers for Oracle... Anyone? Anthony From jno@glasnet.ru Tue May 5 10:42:14 1998 From: jno@glasnet.ru (Eugene Dvurechenski) Date: Tue, 5 May 1998 13:42:14 +0400 (WSU DST) Subject: [DB-SIG] Support for Illustra-python? In-Reply-To: <35481F15.CDEA9775@axis.com.au> Message-ID: AFAIK, there is no Illustra any more... On Thu, 30 Apr 1998, John Lehmann wrote: > 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. > > ------------------------------------------------------ > DB-SIG maillist - DB-SIG@python.org > http://www.python.org/mailman/listinfo/db-sig > --- SY, [ mailto:jno@glas.apc.org ICQ:5888477 ] jno (PRIVATE PERSON) [ http://www.glasnet.ru/~jno ] a GlasNet technie [ http://www.aviation.ru/ ] From A.M.INGRALDI@larc.nasa.gov Tue May 5 20:32:22 1998 From: A.M.INGRALDI@larc.nasa.gov (Anthony M. Ingraldi) Date: Tue, 5 May 1998 15:32:22 -0400 Subject: [DB-SIG] informixdb problem Message-ID: Hello, I have obtained a copy of the ifxdbmodule package from the python ftp site and I am having trouble getting it to work. System specifics are as follows: OS: Solaris 2.5.1 Python: 1.5.1 gcc: 2.7.2.3 ESQL: I get conflicting information here If I execute /usr/local/informix/bin/esqlvers, I get INFORMIX-ESQL Version 9.12.UC2 If I execute /usr/local/informix/lib/esql/esqlc -v, I get INFORMIX-ESQL Version 7.24.UC4 When I try to import the _informixdb.so module, I get the following: >>> import _informixdb Traceback (innermost last): File "", line 1, in ? ImportError: ld.so.1: python: fatal: relocation error: symbol not found: gl_setextfunc: referenced in ./_informixdb.so >>> Any help you could offer would be appreciated. -- Tony Ingraldi | e-mail: A.M.INGRALDI@LaRC.NASA.GOV NASA Langley Research Center | Mail Stop 267 | Phone : (757) 864-3039 Hampton, VA 23681-2199 | Fax : (757) 864-7892 From mdt@mdt.in-berlin.de Tue May 5 16:58:11 1998 From: mdt@mdt.in-berlin.de (Michael Dietrich) Date: Tue, 5 May 1998 17:58:11 +0200 Subject: [DB-SIG] mSQL interface Message-ID: <19980505175811.F1591@mdt.in-berlin.de> hi all, i did some enhancements for the mSQL-interface for python and wonder how to give it back to people that are interested in that. also anthony told me that other people did some other bugfixes and enhancements and i would like to merge those into my version but don't know who they are. last i would do a python-db-api conform interface for mSQL if enough people are interested in that. but o don't even know how many people use mSQL with python or are interested if a conform api exists. can you help me to answer these questions? greetings, michael -- -----------------------------------------------------Michael Dietrich private mailto:mdt@mdt.in-berlin.de http://mdt.in-berlin.de/~mdt commercial mailto:mdt@stargate.all.de fax:+49.171.8029279 PGP KeyID:28033EFD From johnl@axis.com.au Wed May 6 02:00:07 1998 From: johnl@axis.com.au (John Lehmann) Date: Wed, 06 May 1998 11:00:07 +1000 Subject: [DB-SIG] mSQL interface References: <19980505175811.F1591@mdt.in-berlin.de> Message-ID: <354FB617.249D5712@axis.com.au> Michael Dietrich wrote: > > last i would do a python-db-api conform interface for mSQL if enough > people are interested in that. but o don't even know how many people > use mSQL with python or are interested if a conform api exists. > I was starting to look at doing this for the mySQL module. As there seems to be a convert-mSQL-to-mySQL script in the mySQL distribution, I would be interested such an api-conformant version of the module :) Actually I was going to look at wrapping the mySQL-api in swig and then writing a db-sig conformant wrapper in python, as my C is rusty. Is this a stupid idea? -- | John J. Lehmann, johnl@axis.com.au + If a job is scheduled during the 'witching hour' - the job will + either be run once (if the actual time exists twice) or not at + all (if the actual time never exists) From mal@lemburg.com Wed May 6 10:25:41 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 06 May 1998 11:25:41 +0200 Subject: [DB-SIG] mSQL interface References: <19980505175811.F1591@mdt.in-berlin.de> <354FB617.249D5712@axis.com.au> Message-ID: <35502C95.6323DD46@lemburg.com> John Lehmann wrote: > > Actually I was going to look at wrapping the mySQL-api in swig and then > writing a db-sig conformant wrapper in python, as my C is rusty. Is > this a stupid idea? Not at all. FYI, mySQL (and I think mSQL too) has an ODBC driver which works pretty fine with iODBC, the free Unix ODBC driver manager. I've got that running with mxODBC. There's one quirk though, that makes a native interface interesting: the ODBC driver for mySQL expects string input for *all* types -- the conversion is done auto- matically by mxODBC (well, the next release of it), but it could cause the input data to be slightly inaccurate (e.g. for floats). -- Marc-Andre Lemburg ---------------------------------------------------------------------- | Python Pages: http://starship.skyport.net/~lemburg/ | ------------------------------------------------------- From Anthony Baxter Wed May 6 11:57:54 1998 From: Anthony Baxter (Anthony Baxter) Date: Wed, 06 May 1998 20:57:54 +1000 Subject: [DB-SIG] mSQL interface In-Reply-To: Your message of "Wed, 06 May 1998 11:25:41 +0200." <35502C95.6323DD46@lemburg.com> References: <35502C95.6323DD46@lemburg.com> <19980505175811.F1591@mdt.in-berlin.de> <354FB617.249D5712@axis.com.au> Message-ID: <199805061057.UAA12088@koro.off.connect.com.au> >>> "M.-A. Lemburg" wrote > John Lehmann wrote: > > > > Actually I was going to look at wrapping the mySQL-api in swig and then > > writing a db-sig conformant wrapper in python, as my C is rusty. Is > > this a stupid idea? > > got that running with mxODBC. There's one quirk though, that makes > a native interface interesting: the ODBC driver for mySQL expects > string input for *all* types -- the conversion is done auto- > matically by mxODBC (well, the next release of it), but it could > cause the input data to be slightly inaccurate (e.g. for floats). Eurgh. My original mSQL interface had the same... feature. It's a total pain in the bottom after a while - I only did it initially because I was lazy :) FWIW, I'd advocate throwing out the existing code, and doing something with SWIG to wrap both mSQL and mySQL. Anthony From A.M.INGRALDI@larc.nasa.gov Mon May 11 22:40:06 1998 From: A.M.INGRALDI@larc.nasa.gov (Anthony M. Ingraldi) Date: Mon, 11 May 1998 17:40:06 -0400 Subject: [DB-SIG] informixdb problem In-Reply-To: Message-ID: At 3:32 PM -0400 5/5/98, Anthony M. Ingraldi wrote: >I have obtained a copy of the ifxdbmodule package from the python ftp site >and I am having trouble getting it to work. ... >When I try to import the _informixdb.so module, I get the following: > >>>> import _informixdb >Traceback (innermost last): > File "", line 1, in ? >ImportError: ld.so.1: python: fatal: relocation error: symbol not found: >gl_setextfunc: referenced in ./_informixdb.so >>>> I have found that I needed to make some changes to the Makefile in order to successfully import the module. The key change is on the LIBS definition line old definition: LIBS=-lasf -lsql -los -lgen new definition: LIBS=-lixsql -lixasf -lixgen -lixos -lixgls -lnsl -lsocket -laio -lm /usr/local/ informix/lib/esql/checkapi.o -lixglx (Typing "esql -libs" at a command prompt gave me the necessary information.) -- Tony Ingraldi | e-mail: A.M.INGRALDI@LaRC.NASA.GOV NASA Langley Research Center | Mail Stop 267 | Phone : (757) 864-3039 Hampton, VA 23681-2199 | Fax : (757) 864-7892 From harri.pasanen@trema.com Wed May 20 11:29:24 1998 From: harri.pasanen@trema.com (Harri PASANEN) Date: Wed, 20 May 1998 12:29:24 +0200 Subject: [DB-SIG] Sybase module References: Message-ID: <3562B084.5034A3E@trema.com> Has anyone tried to compile the Sybase module for NT? Thanks, Harri From jim.fulton@Digicool.com Wed May 20 14:43:42 1998 From: jim.fulton@Digicool.com (Jim Fulton) Date: Wed, 20 May 1998 09:43:42 -0400 Subject: [DB-SIG] Sybase module References: <3562B084.5034A3E@trema.com> Message-ID: <3562DE0E.135D@digicool.com> Harri PASANEN wrote: > > Has anyone tried to compile the Sybase module for NT? I've compiled it for NT. You want the dll? Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From harri.pasanen@trema.com Wed May 20 15:37:57 1998 From: harri.pasanen@trema.com (Harri PASANEN) Date: Wed, 20 May 1998 16:37:57 +0200 Subject: [DB-SIG] Sybase module References: <3562B084.5034A3E@trema.com> <3562DE0E.135D@digicool.com> Message-ID: <3562EAC5.D1E7A1F3@trema.com> Jim Fulton wrote: > > Harri PASANEN wrote: > > > > Has anyone tried to compile the Sybase module for NT? > > I've compiled it for NT. You want the dll? > > Jim > Thanks for the offer, but actually I already compiled it. I'm bit unsure how the following are supposed to be handled under NT: PyObject *DbiString; PyObject *DbiRaw; PyObject *DbiRowId; PyObject *DbiNumber; PyObject *DbiDate; PyObject *DbiNoError; PyObject *DbiOpError; PyObject *DbiProgError; PyObject *DbiIntegrityError; PyObject *DbiDataError; PyObject *DbiInternalError; First I got all these as undefined symbols during linking, then I just added the above list to dbi.c and seems to work... Another offshoot question: Our sybase server runs on a SPARC-Solaris box, and running the identical python client on NT and another SPARC-Solaris box gives the result that NT-client seems roughly 3 times slower than doing the same from another SPARC Solaris box. The NT cpu is practically idle during the process, so it must be something with sybase client libs / or network. Anyone have experience speeding up Sybase NT clients? Thanks, Harri From Tod Olson Wed May 20 16:58:23 1998 From: Tod Olson (Tod Olson) Date: Wed, 20 May 1998 10:58:23 -0500 Subject: [DB-SIG] Sybase module In-Reply-To: Your message of "Wed, 20 May 1998 16:37:57 +0200" References: <3562EAC5.D1E7A1F3@trema.com> Message-ID: <199805201558.KAA10458@stone.lib.uchicago.edu> >>>>> "HP" == Harri PASANEN writes: HP> Our sybase server runs on a SPARC-Solaris box, and running the HP> identical python client on NT and another SPARC-Solaris box gives HP> the result that NT-client seems roughly 3 times slower than doing HP> the same from another SPARC Solaris box. The NT cpu is HP> practically idle during the process, so it must be something with HP> sybase client libs / or network. Some time ago, there was a problem with NT making a TCP/IP connection to Solaris. (I wish I could remember the versions.) MS was doing something non-standard in their TCP/IP stack, and Sun hadn't specifically tested MS compatibility, or somesuch. If you're running an old or unpatched Solaris, you might check for relevant patches, or you might check that NT has the most recent service pack installed. Or this could be a red herring. 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 pgodman@halcyon.com Wed May 20 23:32:54 1998 From: pgodman@halcyon.com (Peter Godman) Date: Wed, 20 May 1998 15:32:54 -0700 (PDT) Subject: [DB-SIG] Sybase module In-Reply-To: <3562EAC5.D1E7A1F3@trema.com> Message-ID: > > Thanks for the offer, but actually I already compiled it. > I'm bit unsure how the following are supposed to > be handled under NT: > > PyObject *DbiString; > PyObject *DbiRaw; > PyObject *DbiRowId; > PyObject *DbiNumber; > PyObject *DbiDate; > > PyObject *DbiNoError; > PyObject *DbiOpError; > PyObject *DbiProgError; > PyObject *DbiIntegrityError; > PyObject *DbiDataError; > PyObject *DbiInternalError; > > First I got all these as undefined symbols during linking, > then I just added the above list to dbi.c and seems to work... > Hmmmm. It's a shame this stops you compiling since the module has no real support for dbi types. I'm glad to hear it works on NT (assuming you're referring to the module I wrote!). Anyone try Win95? Does success on NT imply success on 95? Sorry for my windows ignorance. Has anyone used it to connect to M$ SQL Server? On NT/95? Sadly, I understand the new version of MSSS will have an api that is a significant departure from client library, so this module won't work for M$ SQL Server any more. From MHammond@skippinet.com.au Thu May 21 00:11:52 1998 From: MHammond@skippinet.com.au (Mark Hammond) Date: Thu, 21 May 1998 09:11:52 +1000 Subject: [DB-SIG] Sybase module Message-ID: <005901bd8444$b05e6220$0a01a8c0@skippy.skippinet.com.au> >> Thanks for the offer, but actually I already compiled it. >> I'm bit unsure how the following are supposed to >> be handled under NT: >> >> PyObject *DbiString; >> PyObject *DbiRaw; I think that these are public symbols exported by the DBI DLL. ODBC has a similar issue...You need to link with the dbi.lib file, and at runtime you will need to import dbi before your module. >I'm glad to hear it works on NT (assuming you're referring to the module I >wrote!). Anyone try Win95? Does success on NT imply success on 95? We wish :-) [However, I suppose for some things it does a little, and at least you know you are a long way there :-] Mark. From mdt@mdt.in-berlin.de Thu May 21 00:28:29 1998 From: mdt@mdt.in-berlin.de (Michael Dietrich) Date: Thu, 21 May 1998 01:28:29 +0200 Subject: [DB-SIG] mSQL version Message-ID: <19980521012829.B16416@mdt.in-berlin.de> second time i ask this: how can i upload my version of the mSQL interface to python.org? i merged several versions and fixed some bugs, made a simple makefile an provided additional documentation. -- see header From mal@lemburg.com Thu May 21 10:58:39 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 21 May 1998 11:58:39 +0200 Subject: [DB-SIG] DB-API 1.1 Message-ID: <3563FACF.7663D00E@lemburg.com> I'd like to start discussing updating/extending the DB-API 1.0 to a new version. IMHO, this needs to be done to a. clearify a few minor tidbits b. enable a more informative exception mechanism You can have a look at an alpha version of 1.1 at: http://starship.skyport.net/~lemburg/DatabaseAPI-1.1.html Major additions are the new dbi-exception classes (which use the 1.5 class exception mechanism, thus allowing to catch all DB-related exceptions with the Error-base class, or just a specific subclass of it), .nextset() and a few statements about the return values of the .fetch*() methods in case there's nothing left to be fetched. Some other suggestions: 1. Instead of defining the connection constructor to be named , I think Connect(...) is a better choice (helps porting applications from one DB to another. 2. We should come up with a reasonable package structure for database access, e.g. to give the discussion a starting point: [Database] [] [dbi] [] [dbi] You'd then write: from Database.Oracle import * db = Connect('...') c = db.cursor() c.execute('...',dbi.dbiDate(...)) When porting to another database, only 'Oracle' would have to changed to the other DBs name (in the ideal case ;-). 3. cursor.description should be well defined, always return 7-tuples, but allow None to be passed as synonym for 'data not available'. 4. Fix some standard for date/time values. I won't comment, since I am a little biased on this one ;-) Awaiting your comments. -- Marc-Andre Lemburg ---------------------------------------------------------------------- | Python Pages: http://starship.skyport.net/~lemburg/ | ------------------------------------------------------- From jim.fulton@Digicool.com Thu May 21 14:42:47 1998 From: jim.fulton@Digicool.com (Jim Fulton) Date: Thu, 21 May 1998 09:42:47 -0400 Subject: [DB-SIG] mSQL version References: <19980521012829.B16416@mdt.in-berlin.de> Message-ID: <35642F57.6C2B@digicool.com> Michael Dietrich wrote: > > second time i ask this: how can i upload my version of the mSQL > interface to python.org? i merged several versions and fixed some > bugs, made a simple makefile an provided additional documentation. See ftp://ftp.python.org/pub/python/contrib/ for pointers to instructions. -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From mal@lemburg.com Tue May 26 22:21:45 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 26 May 1998 23:21:45 +0200 Subject: [DB-SIG] DB-API 1.1 References: <3563FACF.7663D00E@lemburg.com> Message-ID: <356B3269.EDBD1D8@lemburg.com> M.-A. Lemburg wrote: > > I'd like to start discussing updating/extending the DB-API 1.0 to > a new version. IMHO, this needs to be done to > a. clearify a few minor tidbits > b. enable a more informative exception mechanism > > You can have a look at an alpha version of 1.1 at: > http://starship.skyport.net/~lemburg/DatabaseAPI-1.1.html Looks like everybody is too busy ... oh well. I'll wait another week or so then and repost the RFC. Until then: I will be releasing a new version of mxODBC in the next few days. If you want to take a look at the pre-release version, you can download it from: http://starship.skyport.net/~lemburg/mxODBC-pre0.8.zip It is multi-database enabled, that is you can connect to multiple different databases at the same time, and provides setups for Adabas, Solid and mySQL. Oracle/Unix may work with the Intersolv ODBC drivers, but I haven't heard of a definite answer yet. It also compiles against the free Microsoft ODBC manager (well, previous versions have -- can't test it myself). Feel free to provide more setups. The more database connectivity we get for Python, the better. -- Marc-Andre Lemburg ---------------------------------------------------------------------- | Python Pages: http://starship.skyport.net/~lemburg/ | ------------------------------------------------------- From harri.pasanen@trema.com Fri May 29 13:05:07 1998 From: harri.pasanen@trema.com (Harri PASANEN) Date: Fri, 29 May 1998 14:05:07 +0200 Subject: [DB-SIG] Sybase module References: Message-ID: <356EA473.9C386C80@trema.com> Hi, I'm having slight problems with Peter Godman's sybase module on Windows NT, with Sybase server being on Sparc-Solaris 2.6. The same Python program works every time on Solaris, but on NT it occasionally hangs, always in the same place on cursor.execute(). Looks like there is something locking the cursor, as sp_lock always then gives: fid spid locktype table_id page dbname class context ------ ------ ---------------------------- ----------- ----------- --------------- 0 20 Sh_intent 16003088 0 fk4_0 Cursor Id 1310912 0 20 Sh_page 16003088 6944 fk4_0 Cursor Id 1310912 I only have one python cursor, which I open in the beginning of program and close at the end, so it must be something in the sybase C-api level. I just wonder if anyone has a clue, before I dive in the sources head first? (ActuallyI already took a quick look, but could not really put my finger on it... ;-( ) Thanks, Harri From pgodman@halcyon.com Fri May 29 19:39:16 1998 From: pgodman@halcyon.com (Peter Godman) Date: Fri, 29 May 1998 11:39:16 -0700 (PDT) Subject: [DB-SIG] Sybase module In-Reply-To: <356EA473.9C386C80@trema.com> Message-ID: On Fri, 29 May 1998, Harri PASANEN wrote: > Hi, > > > I'm having slight problems with Peter Godman's sybase module > on Windows NT, with Sybase server being on Sparc-Solaris 2.6. > > The same Python program works every time on Solaris, but > on NT it occasionally hangs, always in the same place on > cursor.execute(). Looks like there is something > locking the cursor, as sp_lock always then gives: > > fid spid locktype table_id page > dbname class > context > ------ ------ ---------------------------- ----------- ----------- > --------------- > 0 20 Sh_intent 16003088 0 > fk4_0 Cursor Id 1310912 > 0 20 Sh_page 16003088 6944 > fk4_0 Cursor Id 1310912 > Hmmm. It's been a long time now, but doesn't the page 0 Sh_intent mean that it's trying to escalate a lock to a table lock? If this were the case, this would mean that Sybase is not realizing that the escalation is unimpeded. This is quite strange. If you only use one cursor, have you tried the program using connection methods rather than cursor methods, i.e. using the execute method of the connection rather than creating a cursor? I'd be interested to see whether it happens there. Can you provide a sequence of DBAPI calls, or some python code? If all else fails, we'll have to turn on state debugging, I guess. Cheers Pete > > I only have one python cursor, which I open in the beginning of program > and close at the end, so it must be something in the sybase C-api level. > > I just wonder if anyone has a clue, before I dive in the sources head > first? > (ActuallyI already took a quick look, but could not really put my > finger on it... ;-( ) > > > Thanks, > > Harri > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://www.python.org/mailman/listinfo/db-sig > From billtut@microsoft.com Fri May 29 19:45:33 1998 From: billtut@microsoft.com (Bill Tutt) Date: Fri, 29 May 1998 11:45:33 -0700 Subject: [DB-SIG] Sybase module Message-ID: <4D0A23B3F74DD111ACCD00805F31D81005B04C20@red-msg-50.dns.microsoft.com> You're also on NT, you could use the ODBC module that comes with PythonWin. Bill -----Original Message----- From: Peter Godman [mailto:pgodman@halcyon.com] Sent: Friday, May 29, 1998 11:39 AM To: Harri PASANEN Cc: db-sig@python.org Subject: Re: [DB-SIG] Sybase module On Fri, 29 May 1998, Harri PASANEN wrote: > Hi, > > > I'm having slight problems with Peter Godman's sybase module > on Windows NT, with Sybase server being on Sparc-Solaris 2.6. > > The same Python program works every time on Solaris, but > on NT it occasionally hangs, always in the same place on > cursor.execute(). Looks like there is something > locking the cursor, as sp_lock always then gives: > > fid spid locktype table_id page > dbname class > context > ------ ------ ---------------------------- ----------- ----------- > --------------- > 0 20 Sh_intent 16003088 0 > fk4_0 Cursor Id 1310912 > 0 20 Sh_page 16003088 6944 > fk4_0 Cursor Id 1310912 > Hmmm. It's been a long time now, but doesn't the page 0 Sh_intent mean that it's trying to escalate a lock to a table lock? If this were the case, this would mean that Sybase is not realizing that the escalation is unimpeded. This is quite strange. If you only use one cursor, have you tried the program using connection methods rather than cursor methods, i.e. using the execute method of the connection rather than creating a cursor? I'd be interested to see whether it happens there. Can you provide a sequence of DBAPI calls, or some python code? If all else fails, we'll have to turn on state debugging, I guess. Cheers Pete > > I only have one python cursor, which I open in the beginning of program > and close at the end, so it must be something in the sybase C-api level. > > I just wonder if anyone has a clue, before I dive in the sources head > first? > (ActuallyI already took a quick look, but could not really put my > finger on it... ;-( ) > > > Thanks, > > Harri > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://www.python.org/mailman/listinfo/db-sig > _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://www.python.org/mailman/listinfo/db-sig