From jtt@hnc.com Fri Nov 3 19:36:26 2000 From: jtt@hnc.com (Turney, James) Date: Fri, 3 Nov 2000 11:36:26 -0800 Subject: [DB-SIG] Building DCOracle-1.3.2 on AIX 4.3.2 with Oracle 734 Message-ID: <72A838A51366D211B3B30008C7F4D36304F49BCD@pchnc.hnc.com> I am trying to build the DCOracle-1.3.2 package on AIX 4.3.2 using the AIX compiler and Oracle 7.3.4. Has anyone got this to work. It seems to be having trouble linking (lots of what looks like python related unresolved symbol) Thanks Jim Turney jtt@hnc.com From tbryan@starship.python.net Sat Nov 4 17:29:00 2000 From: tbryan@starship.python.net (Tom Bryan) Date: Sat, 4 Nov 2000 09:29:00 -0800 (PST) Subject: [DB-SIG] Building DCOracle-1.3.2 on AIX 4.3.2 with Oracle 734 In-Reply-To: <72A838A51366D211B3B30008C7F4D36304F49BCD@pchnc.hnc.com> Message-ID: On Fri, 3 Nov 2000, Turney, James wrote: > I am trying to build the DCOracle-1.3.2 package on AIX 4.3.2 using the AIX > compiler and Oracle 7.3.4. Has anyone got this to work. > It seems to be having trouble linking (lots of what looks like python > related unresolved symbol) I had a tough time building DCOracle the first time on DEC/Compaq's UNIX (now Tru64 UNIX). I haven't used AIX, but we might be able to offer some suggestions if you'd post some output from the compilation process in addition to some information about the flags used during compilation. ---Tom From gonter@maestria.wu-wien.ac.at Sat Nov 4 20:20:55 2000 From: gonter@maestria.wu-wien.ac.at (Gerhard Gonter) Date: Sat, 4 Nov 2000 21:20:55 +0100 (MEZ) Subject: [DB-SIG] Building DCOracle-1.3.2 on AIX 4.3.2 with Oracle 734 In-Reply-To: <72A838A51366D211B3B30008C7F4D36304F49BCD@pchnc.hnc.com> Message-ID: <200011042020.VAA57070@maestria.wu-wien.ac.at> On Fri, 3 Nov 2000, Turney, James wrote: > I am trying to build the DCOracle-1.3.2 package on AIX 4.3.2 using the AIX > compiler and Oracle 7.3.4. Has anyone got this to work. > It seems to be having trouble linking (lots of what looks like python > related unresolved symbol) I sucessfully compiled DCOoracle 1.3.0 on AIX 4.2.1 with Oracle 8.0.5 in a brute force attack, that is, I used a Perl script (sorry, I'm not fluent enough with Python) that tried different combinations of library arrangements for a whole night. The shared object is now in daily use, so it seems to work. If someone is interested in that script, drop me a line. +gg -- Gerhard.Gonter@wu-wien.ac.at Fax: +43/1/31336/702 g.gonter@ieee.org Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From tbryan@starship.python.net Sat Nov 4 23:46:42 2000 From: tbryan@starship.python.net (Tom Bryan) Date: Sat, 4 Nov 2000 15:46:42 -0800 (PST) Subject: [DB-SIG] Building DCOracle-1.3.2 on AIX 4.3.2 with Oracle 734 In-Reply-To: <200011042020.VAA57070@maestria.wu-wien.ac.at> Message-ID: On Sat, 4 Nov 2000, Gerhard Gonter wrote: > On Fri, 3 Nov 2000, Turney, James wrote: > > I am trying to build the DCOracle-1.3.2 package on AIX 4.3.2 using the AIX > > compiler and Oracle 7.3.4. Has anyone got this to work. > > It seems to be having trouble linking (lots of what looks like python > > related unresolved symbol) > > I sucessfully compiled DCOoracle 1.3.0 on AIX 4.2.1 with Oracle 8.0.5 > in a brute force attack, that is, I used a Perl script (sorry, I'm not > fluent enough with Python) that tried different combinations of library > arrangements for a whole night. The shared object is now in daily use, > so it seems to work. If someone is interested in that script, drop me > a line. I think I sent a notice to petrilli last year, but the README for DCOracle's build says """ Debugging Setup files Linking Oracle programs requires linking against many libraries and libraries must often be linked multiple times. The libraries that must be linked and their order varies from one revision of Oracle to another and from platform to platform. """ I redid my division's makefiles at work (we were changing compilers and upgrading to Oracle 8i) last year. I found (after hours of tracing through Oracle's make macros and hours of digging through Oracle's website) that the link flags for Oracle can be reduced to -lclntsh Basically, they took all of the object files used to build all of those libraries that have to be linked multiple times and linked them into a single shared libclntsh.so. I think that the library lives in $ORACLE_HOME/lib, and you'll have to make sure that it's in your LD_LIBRARY_PATH. Since DCOracle is designed for use as a shared object, I strongly recommend using the -lclntsh flag. It really simplifies life. I still don't understand why Oracle doesn't "advertise" the libclntsh.so method of linking. See, for example, http://www.oracle.com/oramag/oracle/98-Jan/tlbox.html By the way, you'll probably need to add a few extra OS libraries that -lclntsh might need. For example, at work we use the following link line for Pro*C/C++ programs on Compaq's Tru64 UNIX: -lclntsh -lexc -lmld -lrt -laio_raw -lm -lpthread Resolving unfound symbols in /usr/lib is much easier than doing it in Oracle's library directories. When I get to work on Monday, I can doublecheck the setup file that I used for DCOracle, but it used something like the above link line. It's incredible what you can get away with if you have enough market share. :) ---Tom From mal@lemburg.com Wed Nov 15 10:05:43 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 15 Nov 2000 11:05:43 +0100 Subject: [DB-SIG] ANN: New URL for the mx-Extensions (mxDateTime,mxODBC,etc) Message-ID: <3A125FF7.C22D379D@lemburg.com> Hi everybody, due to the frequent downtimes of Starship.python.net I am moving all my Python Pages including the mx Extensions to a new site which will hopefully provide a more stable platform. Python Pages URL ---------------- You can find everything at this new URL: http://www.lemburg.com/python/ Please update your links to this new URL. Once I get my login for starship to work again, I'll also post an announcement there. mx Extensions URL ------------------ The mx Extensions (e.g. mxDateTime, mxODBC, mxTextTools, etc.) can be downloaded in versions for Python 1.5.2 and Python 2.0 from: http://www.lemburg.com/python/mxExtensions.html Sorry for the delays and mixups during the last few days, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From uche.ogbuji@fourthought.com Thu Nov 16 02:53:33 2000 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Wed, 15 Nov 2000 19:53:33 -0700 Subject: [DB-SIG] ANN: 4Suite 0.9.2 Message-ID: <200011160253.TAA07807@localhost.localdomain> ANN: 4Suite 0.9.2 Fourthought, Inc. (http://Fourthought.com) announces the release of 4Suite 0.9.2 --------------------------- Open source tools for standards-based XML, DOM, XPath, XSLT, RDF XPointer, XLink and object-database development in Python 4Suite is a collection of Python tools for XML processing and object database management. An integrated packaging of several formerly separately-distributed components: 4DOM, 4XPath and 4XSLT, 4RDF, 4ODS 4XPointer and featuring the new 4XLink and DbDOM. News ---- - The 4Suite home page has been moved to http://4Suite.org - 4Suite has moved to a derivative of the Apache license. - 4Suite now workd with Python 2.0 as well as Python 1.5.2. Python 1.6 is not supported, although it might work. Python 1.5.2 support is expected to be dropped in the next release of 4Suite. - PyXML 0.6.2 is still required even if you are using Python 2.0 http://sourceforge.net/projects/pyxml - Changes to the software: * Introduced 4XLink: A processor to expand XLink attributes * Introduced DbDom: An alpha Dom implmentaiton on top of 4ODS * ODS: Improved the test suites to handle more cases and conform to protocol * cDomlette: added support for methods * 4RDF: Fixes and improvements to serialization, the back end and the API * All: Many improvements to the docs * All: Standardized reader interfaces across DOM implementations * All: Test with python 2.0 * All: PyXML not needed with Python 2.0 * Many misc optimizations * Many misc bug-fixes - We have set up a contest for stories of 4Suite usage. See http://www.4suite.org/contest.epy More info and Obtaining 4Suite ------------------------------ Please see http://4Suite.org From where you can download source, Windows and Linux binaries. 4Suite is distributed under a license similar to that of the Apache Web Server. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +01 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python From uche.ogbuji@fourthought.com Thu Nov 16 16:02:54 2000 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Thu, 16 Nov 2000 09:02:54 -0700 Subject: [DB-SIG] ANN: 4Suite Server 0.9.2 Message-ID: <200011161602.JAA10137@localhost.localdomain> Fourthought, Inc. (http://Fourthought.com) announces the release of 4Suite Server 0.9.2 --------------------------- An open source XML data server based on open standards implemented using 4Suite and other tools 4Suite Server is a platform for handling XML processing needs in application development. It is an XML data repository with a rules-based engine. It supports DOM access, XSLT transformation, XPath and RDF-based indexing and query, XLink resolution and many other XML services. It also supports other related services such as distributed transactions, and access control lists. It supports remote, cross-platform and cross-language access through CORBA and other request protocols to be added shortly. 4Suite Server is not designed to be a full-blown application server. It provides highly-specialized services for XML processing that can be used with other application servers. 4Suite Server is open-source and free to download. Priority support and customization is available from Fourthought, Inc. For more information on this the home page (http://FourThought.com/4SuiteServer), or contact Fourthought at info@fourthought.com or +1 303 583 9900 The 4Suite Server home page is http://FourThought.com/4SuiteServer From where you can download the software itself or an executive summary thereof, read usage scenarios and find other information. From paul@dubois.ws Tue Nov 21 05:04:11 2000 From: paul@dubois.ws (Paul DuBois) Date: Mon, 20 Nov 2000 23:04:11 -0600 Subject: [DB-SIG] Why the varying paramstyles in DB-API? Message-ID: Why are there so many different paramstyles for DB-API? Given that one benefit of the API is to provide a uniform access method across database engines, doesn't the non-uniformity of parameter styles diminish the extent to which that benefit can be realized? From gstein@lyra.org Tue Nov 21 07:40:16 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 20 Nov 2000 23:40:16 -0800 Subject: [DB-SIG] Why the varying paramstyles in DB-API? In-Reply-To: ; from paul@dubois.ws on Mon, Nov 20, 2000 at 11:04:11PM -0600 References: Message-ID: <20001120234016.H21426@lyra.org> On Mon, Nov 20, 2000 at 11:04:11PM -0600, Paul DuBois wrote: > Why are there so many different paramstyles for DB-API? > Given that one benefit of the API is to provide a uniform > access method across database engines, doesn't the non-uniformity > of parameter styles diminish the extent to which that benefit > can be realized? The idea is to provide a *similar* access method across engines. If you use DBAPI against one database, then you know how to use it against others. But that doesn't mean it is used exactly the same. There are way too many differences between databases to create any kind of system that can encompass all of them. ODBC attempts to do so, but even that has a bazillion runtime query mechanisms to find out *how* to run against the database. And even then, you're probably *still* not portable. For example: cursors aren't portable, certain SQL functions, some formatting stuff, or even SQL itself. The DBAPI helps you transition, but it doesn't create a totally safe "plug in whatever you want" system. Specifically, in this case, the formatting codes are database-specific. The DBAPI does not attempt to enforce a particular form, which would simply serve to make every DBAPI developer have to implement a lot of glue if that form did not correspond to their database's form. Some databases use '?', others use %1, others something else. Those changes are reflected up to the DBAPI client. Marc-Andre started some work to try to collect all the differences between databases, then to use that information to write a higher-level API that hides the differences. More power to him :-), but I've been down that road before. The result is the DBAPI: similar across databases, but it isn't going to break a leg for you because it simply can't get rid of all differences. Cheers, -g -- Greg Stein, http://www.lyra.org/ From manyong@gnu.org Wed Nov 22 07:10:39 2000 From: manyong@gnu.org (Man-Yong Lee) Date: Wed, 22 Nov 2000 16:10:39 +0900 Subject: [DB-SIG] DB2 module version 0.93 Message-ID: <3A1B716F.FC4BCCD0@gnu.org> Hi, DB-SIG people, I've just fixed silly bug related to BIGINT type. The mistake was using PyLong_FromLong instead of PyLong_FromDouble. You can get new module from: ftp://people.linuxkorea.co.kr/pub/DB2/ Have a nice day! -- Happy Python! Man-Yong (Bryan) Lee From bimal291@hotmail.com Thu Nov 23 05:25:52 2000 From: bimal291@hotmail.com (bimal shah) Date: Thu, 23 Nov 2000 05:25:52 -0000 Subject: [DB-SIG] (no subject) Message-ID: Dear friends, i was executing the following prog: # \user\local\bin\python import dbi, odbc # ODBC modules try: s = odbc.odbc('bimal/bimal/bimal') # i kept system DSN=bimal and in advanced settings # login=bimal & password=bimal cur = s.cursor() cur.execute('select * from bimal1') print cur.description for tup in cur.description: print tup[0], print while 1: rec = cur.fetchmany(10) if not rec: break print rec except NameError,e: print 'error ', e, 'undefined' i am getting follwing traceback: Traceback (most recent call last): File "d:\python20\pythonwin\pywin\framework\scriptutils.py", line 301, in RunScript exec codeObject in __main__.__dict__ File "D:\Python20\win32\python fiels\dbtest.py", line 10, in ? s = odbc.odbc('bimal/bimal/bimal') dbi.operation-error: [Microsoft][ODBC Microsoft Access Driver]General error Not enough information to connect to this DSN with SQLConnect. Use SQLDriverConnect. in LOGIN >>> so please guide me for this problem. I am feeling that it is not importing my odbc.pyd properly. _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From mal@lemburg.com Thu Nov 23 09:14:03 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 23 Nov 2000 10:14:03 +0100 Subject: [DB-SIG] MS Access problem (no subject) References: Message-ID: <3A1CDFDB.5E498224@lemburg.com> bimal shah wrote: > > Dear friends, > i was executing the following prog: > > # \user\local\bin\python > > import dbi, odbc # ODBC modules > > try: > s = odbc.odbc('bimal/bimal/bimal') > # i kept system DSN=bimal and in advanced settings > # login=bimal & password=bimal > > cur = s.cursor() > cur.execute('select * from bimal1') > print cur.description > for tup in cur.description: > print tup[0], > print > while 1: > rec = cur.fetchmany(10) > if not rec: break > print rec > except NameError,e: > print 'error ', e, 'undefined' > > i am getting follwing traceback: > > Traceback (most recent call last): > File "d:\python20\pythonwin\pywin\framework\scriptutils.py", line 301, in > RunScript > exec codeObject in __main__.__dict__ > File "D:\Python20\win32\python fiels\dbtest.py", line 10, in ? > s = odbc.odbc('bimal/bimal/bimal') > dbi.operation-error: [Microsoft][ODBC Microsoft Access Driver]General error > Not enough information to connect to this DSN with SQLConnect. Use > SQLDriverConnect. in LOGIN > >>> Have you tried the same thing with user id and password as parameters to .odbc() ? If the problem persists, you must be using some kind of special setup which can only be dealt with using SQLDriverConnect. I that case, I'd suggest switching to mxODBC which you can download from my Python Pages. > so please guide me for this problem. I am feeling that > it is not importing my odbc.pyd properly. I don't think this is the problem: it's the MS ODBC manager that's generating the error message, so the connection is there. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Andreas.Trawoeger@wgkk.sozvers.at Thu Nov 23 11:38:20 2000 From: Andreas.Trawoeger@wgkk.sozvers.at (Trawoeger, Andreas) Date: Thu, 23 Nov 2000 12:38:20 +0100 Subject: [DB-SIG] Could someone please write a Python DB Tutorial? Message-ID: Hi! I started with Python DB programming three days ago and finally succeeded in most of what I wanted to do, but I had a really hard time to get there. My primary goal was to be able to access the SQL Database of our M$ System Management Server from my Linux box I'm using for network monitoring. At first I did thought this couldn't be too difficult. I just want to pass a small SELECT statement to the SQL-Server and process the result using Python on my Linux box. So I started to read the Python Database API. Which gave me absolutely no clue how to do what I wanted to do. It is a precise description of all functions of the API, but that's it. I can give you a precise description of the most important verbs and nouns of the German language. You will still find yourself have a lot of troubles writing a sentence in German. The most useful information I have found are the OdbcHints for PythonWin. Which helped me to understand the basic DB API calls and how to solve part of my problems on a NT box, but I hadthe additional problem of porting the script from NT to Linux. That's the point where I really got stuck. There is no in depth documentation about how to use the DB API and only small hints about M$ SQL connection on Linux on the mxODBC Homepage. It took me a 15 hour working day including a nightly hacking session till 2am to solve my Linux -> NT connection problem using the EasySoft ODBC<->ODBC Gateway. I also thing that I'm going to have a hard time to use more API calls then: connect, cursor, execute, fetchall. So I would really like to ask you to write a short Tutorial. Giving a short overview about all the available modules and which module you can use for which purpose and a couple of examples how to use the Python DB API. (The simple tip: For M$ SQL use the EasySoft ODBC Gateway could have saved me 4 hours of desperate Google searches). cu andreas --- If you wrap the Internet around every person on the planet and spin the planet, software flows in the network. - Eben Moglen's Metaphorical Corollary to Faraday's Law From mal@lemburg.com Thu Nov 23 12:01:27 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 23 Nov 2000 13:01:27 +0100 Subject: [DB-SIG] Could someone please write a Python DB Tutorial? References: Message-ID: <3A1D0717.17C9B76F@lemburg.com> "Trawoeger, Andreas" wrote: > > Hi! > > I started with Python DB programming three days ago and finally succeeded in > most of what I wanted to do, but I had a really hard time to get there. > > My primary goal was to be able to access the SQL Database of our M$ System > Management Server from my Linux box I'm using for network monitoring. At > first I did thought this couldn't be too difficult. I just want to pass a > small SELECT statement to the SQL-Server and process the result using Python > on my Linux box. > > So I started to read the Python Database API. Which gave me absolutely no > clue how to do what I wanted to do. It is a precise description of all > functions of the API, but that's it. I can give you a precise description of > the most important verbs and nouns of the German language. You will still > find yourself have a lot of troubles writing a sentence in German. > > The most useful information I have found are the OdbcHints for PythonWin. > Which helped me to understand the basic DB API calls and how to solve part > of my problems on a NT box, but I hadthe additional problem of porting the > script from NT to Linux. The DB topic guide on python.org has some hints and tutorials about how to use the DB API and there are also a few Python books which contain chapters about this, e.g. the Python book about Win32 programming. > That's the point where I really got stuck. There is no in depth > documentation about how to use the DB API and only small hints about M$ SQL > connection on Linux on the mxODBC Homepage. It took me a 15 hour working day > including a nightly hacking session till 2am to solve my Linux -> NT > connection problem using the EasySoft ODBC<->ODBC Gateway. Was the problem related to mxODBC or EasySoft ? Have you read the mxODBC Configuration Guide by Paul Boddie ? > I also thing that I'm going to have a hard time to use more API calls then: > connect, cursor, execute, fetchall. > > So I would really like to ask you to write a short Tutorial. Giving a short > overview about all the available modules and which module you can use for > which purpose and a couple of examples how to use the Python DB API. (The > simple tip: For M$ SQL use the EasySoft ODBC Gateway could have saved me 4 > hours of desperate Google searches). How about writing down you experiences like Paul Boddie did and putting the results up on the web somewhere ?! This will help others configure Python database access more easily. BTW, I'd suggest asking in a forum like this before taking off into an uncertain direction. The subscribers on this list do have a lot of experience and may well be able to point you to a possible solution. For the Linux -> MS SQL access I would have pointed you to the OpenLink/Merant ODBC driver kits which should allow you to connect from Linux to NT. Another possibility would have been to try to use a Sybase ODBC driver for Linux -- MS SQL Server's wire protocol is said to be compatible with Sybase's. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pl@tintin.smbh.univ-paris13.fr Thu Nov 23 23:13:07 2000 From: pl@tintin.smbh.univ-paris13.fr (Patrick Ladam) Date: Thu, 23 Nov 2000 15:13:07 -0800 Subject: [DB-SIG] dbm to gdbm conversion Message-ID: <3A1DA483.558AB05@tintin.smbh.univ-paris13.fr> Hi all, I am a real newbie in python (and db too...) and so will ask what you will probably consider a dumb newbie question... Here is the situation: I use a scientific soft that works both on a unix and a linux platform. This soft uses dbm on unix and gdbm on linux as you guessed. thus I'd like to convert the dbm databases into gdbm databases (and vice-versa) for exchangin data. I could not find any converting function in any module (dbm, anydbm, gdbm...) and would like to know if that is doable and ...how to do it. Thanx Bye ------------------------------------------------------------------- | Patrick LADAM | | | Laboratoire CSSB | THE BIG BANG THEORY: | | UFR SMBH | | | 74 rue Marcel Cachin | In the begining there was | | 93017 Bobigny CEDEX | nothing at all. | | e-mail: | | | pl@tintin.smbh.univ-paris13.fr | Then, it exploded... | | Tel: 01 48 38 77 26 / 76 85 | | | Fax: 01 48 38 77 77 | | ------------------------------------------------------------------- From paul@dubois.ws Thu Nov 23 16:48:22 2000 From: paul@dubois.ws (Paul DuBois) Date: Thu, 23 Nov 2000 10:48:22 -0600 Subject: [DB-SIG] Why the varying paramstyles in DB-API? In-Reply-To: <20001120234016.H21426@lyra.org> References: <20001120234016.H21426@lyra.org> Message-ID: >On Mon, Nov 20, 2000 at 11:04:11PM -0600, Paul DuBois wrote: >> Why are there so many different paramstyles for DB-API? >> Given that one benefit of the API is to provide a uniform >> access method across database engines, doesn't the non-uniformity >> of parameter styles diminish the extent to which that benefit >> can be realized? > >The idea is to provide a *similar* access method across engines. If you use >DBAPI against one database, then you know how to use it against others. But >that doesn't mean it is used exactly the same. > >There are way too many differences between databases to create any kind of >system that can encompass all of them. ODBC attempts to do so, but even that >has a bazillion runtime query mechanisms to find out *how* to run against >the database. And even then, you're probably *still* not portable. For >example: cursors aren't portable, certain SQL functions, some formatting >stuff, or even SQL itself. > >The DBAPI helps you transition, but it doesn't create a totally safe "plug >in whatever you want" system. And thus, DB-API developers aren't led, as JDBC developers are sometimes led (falsely) to make claims such as that "you can substitute an entirely different databaseinto your application without so much as a thought about compatibility"? :-) > >Specifically, in this case, the formatting codes are database-specific. The >DBAPI does not attempt to enforce a particular form, which would simply >serve to make every DBAPI developer have to implement a lot of glue if that >form did not correspond to their database's form. Some databases use '?', >others use %1, others something else. Those changes are reflected up to the >DBAPI client. Thanks. When I wrote my message, I was thinking of Perl DBI. Some of the drivers do understand things like :1, :2, etc., but the ? placeholder character seems to be fairly standard (i.e., portable) across drivers. For several of the drivers, ? is provided as an emulation of some other native mechanism, or to compensate for the engine having no placeholder mechanism at all. So for DB-API, is it true to say that providing a portable placeholder machanism (emulating it in the drivers if necessary) simply wasn't a design goal? My question springs out of examination of the MySQLdb driver, which uses the format paramstyle. As far as I can tell, that parameter style gives you printf-style formatting, nothing more, nothing less. It doesn't add quotes around substituted values, doesn't escape special characters, doesn't turn None into NULL in the resulting query string, etc. Using format specifiers that way is something Python does anyway, so I was wondering why that was even called a parameter style at all. It's kind of like calling printf in Perl a parameter style. Thanks for your message. From jon+python-db-sig@unequivocal.co.uk Thu Nov 23 17:15:18 2000 From: jon+python-db-sig@unequivocal.co.uk (Jon Ribbens) Date: Thu, 23 Nov 2000 17:15:18 +0000 Subject: [DB-SIG] Why the varying paramstyles in DB-API? In-Reply-To: ; from paul@dubois.ws on Thu, Nov 23, 2000 at 10:48:22AM -0600 References: <20001120234016.H21426@lyra.org> Message-ID: <20001123171518.C28485@snowy.squish.net> Paul DuBois wrote: > My question springs out of examination of the MySQLdb driver, which uses > the format paramstyle. As far as I can tell, that parameter style gives you > printf-style formatting, nothing more, nothing less. It doesn't add quotes > around substituted values, doesn't escape special characters, doesn't turn > None into NULL in the resulting query string, etc. From an examination of the source, those things are exactly what it *does* do. From mal@lemburg.com Thu Nov 23 17:10:06 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 23 Nov 2000 18:10:06 +0100 Subject: [DB-SIG] dbm to gdbm conversion References: <3A1DA483.558AB05@tintin.smbh.univ-paris13.fr> Message-ID: <3A1D4F6E.405B4850@lemburg.com> Patrick Ladam wrote: > > Hi all, > I am a real newbie in python (and db too...) and so will ask what you > will probably consider a dumb newbie question... > Here is the situation: I use a scientific soft that works both on > a unix and a linux platform. This soft uses dbm on unix and gdbm on > linux as you guessed. > thus I'd like to convert the dbm databases into gdbm databases (and > vice-versa) for exchangin data. > I could not find any converting function in any module (dbm, anydbm, gdbm...) > and would like to know if that is doable and ...how to do it. Wouldn't it be possible to read in the database in Python, store it in a dictionary, write it as pickle to a file and then do the exact reverse on the target machine ? I've never used dbm, but the Python interface looks like it uses a simple mapping interface. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From djc@object-craft.com.au Thu Nov 23 23:04:39 2000 From: djc@object-craft.com.au (Dave Cole) Date: 24 Nov 2000 10:04:39 +1100 Subject: [DB-SIG] Could someone please write a Python DB Tutorial? In-Reply-To: "M.-A. Lemburg"'s message of "Thu, 23 Nov 2000 13:01:27 +0100" References: <3A1D0717.17C9B76F@lemburg.com> Message-ID: >>>>> "mal" == M -A Lemburg writes: mal> BTW, I'd suggest asking in a forum like this before taking off mal> into an uncertain direction. The subscribers on this list do have mal> a lot of experience and may well be able to point you to a mal> possible solution. mal> For the Linux -> MS SQL access I would have pointed you to the mal> OpenLink/Merant ODBC driver kits which should allow you to mal> connect from Linux to NT. Another possibility would have been to mal> try to use a Sybase ODBC driver for Linux -- MS SQL Server's wire mal> protocol is said to be compatible with Sybase's. They are extremely compatible. I have been slowly developing a DB API 2.0 Sybase module. The compliance is pretty good, but still needs more work. The biggest area of non conformance is that you can only use SELECT statements in the Cursor.execute() method. INSERT, UPDATE, DELETE, ... can only be used in the Connect.execute() method. After implementing cursors, I discovered that I was using the wrong set of Sybase API's. At some time in the not-to-distant future, I am going to fix this. The other area of non-conformance is DATETIME values. I still have to integrate mxDateTime... Anyway, I have actually used it on Linux to talk to an MS SQL database with good results. The cursor functionality does not work, but you can simply use the Connect.execute() method. I even wrote a small MSSQL wrapper class which makes it look like cursors work: The Connect.execute() method returns multiple result sets, whereas the Cursor.execute() method only returns a single result set. This makes Connect.execute() useful for getting the results of stored procedures such as sp_help which return multiple result sets. - Dave import Sybase class MSSQLCursor: def __init__(self, db): self.db = db def execute(self, cmd): result_set = self.db.execute(cmd) if len(result_set) > 0: self.rows = result_set[0] else: self.rows = [] self.row_num = 0 def fetchone(self): if self.row_num >= len(self.rows): return None row = self.rows[self.row_num] self.row_num = self.row_num + 1 return row def fetchmany(self, num = 1): if self.row_num + num > len(self.rows): num = len(self.rows) - self.row_num if num > 0: rows = self.rows[self.row_num: self.row_num + num] self.row_num = self.row_num + num else: return [] return rows def fetchall(self): return self.fetchmany(len(self.rows)) def close(self): pass class MSSQL: def __init__(self, server, user, passwd, database = None): db = Sybase.connect(server, user, database) if database: db.execute('use %s' % database) self.db = db def cursor(self): return MSSQLCursor(self.db) def execute(self, cmd): return self.db.execute(cmd) db = MSSQL('pissey', 'sa', '') c = db.cursor() c.execute('select * from sysobjects where type = "P" order by name') print string.join(map(lambda x: x[0], c.fetchall()), '\n') -- http://www.object-craft.com.au From gstein@lyra.org Fri Nov 24 21:39:04 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 24 Nov 2000 13:39:04 -0800 Subject: [DB-SIG] Why the varying paramstyles in DB-API? In-Reply-To: ; from paul@dubois.ws on Thu, Nov 23, 2000 at 10:48:22AM -0600 References: <20001120234016.H21426@lyra.org> Message-ID: <20001124133904.K21426@lyra.org> On Thu, Nov 23, 2000 at 10:48:22AM -0600, Paul DuBois wrote: >... > >The DBAPI helps you transition, but it doesn't create a totally safe "plug > >in whatever you want" system. > > And thus, DB-API developers aren't led, as JDBC developers are sometimes > led (falsely) to make claims such as that "you can substitute an entirely > different databaseinto your application without so much as a thought about > compatibility"? :-) Exactly. Solving that problem is practically impossible, so why try? Why fool people into thinking you can? [ it can be solved with high-level abstractions where you never even see SQL or a cursor or whatever, but *that* abstraction has to build on something... thus, the DBAPI :-) ] > >Specifically, in this case, the formatting codes are database-specific. The > >DBAPI does not attempt to enforce a particular form, which would simply > >serve to make every DBAPI developer have to implement a lot of glue if that > >form did not correspond to their database's form. Some databases use '?', > >others use %1, others something else. Those changes are reflected up to the > >DBAPI client. > > Thanks. When I wrote my message, I was thinking of Perl DBI. Some of the > drivers do understand things like :1, :2, etc., but the ? placeholder > character seems to be fairly standard (i.e., portable) across drivers. > For several of the drivers, ? is provided as an emulation of some other > native mechanism, or to compensate for the engine having no placeholder > mechanism at all. > > So for DB-API, is it true to say that providing a portable placeholder > machanism (emulating it in the drivers if necessary) simply wasn't a > design goal? Correct. Most DB-API implementors simply expose what the database itself uses, rather than trying to do some mappings. Consider the case where you want to do something like: select table1.*, table2.* from table1, table2 where col1=:1 and col2=:1 This is easy for Oracle since that uses the :1 syntax. I can simply say: cursor.execute(stmt, (value,)) But to map the above syntax into ? form, the SQL now looks like: select table1.*, table2.* from table1, table2 where col1=:1 and col2=:1 And the code must pass the input parameter *twice*: cursor.execute(stmt, (value, value)) Doing mappings like this under the covers is certainly possible, but the DB-API doesn't ask for modules to do so. It is certainly nicer to avoid the "?" form since it doesn't support positional or named arguments, but that's up to the implementor. > My question springs out of examination of the MySQLdb driver, which uses > the format paramstyle. As far as I can tell, that parameter style gives you > printf-style formatting, nothing more, nothing less. It doesn't add quotes > around substituted values, doesn't escape special characters, doesn't turn > None into NULL in the resulting query string, etc. You are probably looking at an old version. As somebody already stated, the latest MySQLdb does proper binding, where you don't need to do any quoting. > Using format specifiers > that way is something Python does anyway, so I was wondering why that was > even called a parameter style at all. It's kind of like calling printf > in Perl a parameter style. The printf parameter style *is* valid, presuming the DB-API module does the proper quoting for you. If it doesn't... I agree: it isn't much of a parameter style :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul@dubois.ws Fri Nov 24 21:51:31 2000 From: paul@dubois.ws (Paul DuBois) Date: Fri, 24 Nov 2000 15:51:31 -0600 Subject: [DB-SIG] Why the varying paramstyles in DB-API? In-Reply-To: <20001124133904.K21426@lyra.org> References: <20001120234016.H21426@lyra.org> <20001124133904.K21426@lyra.org> Message-ID: At 1:39 PM -0800 11/24/00, Greg Stein wrote: >On Thu, Nov 23, 2000 at 10:48:22AM -0600, Paul DuBois wrote: > >... > > My question springs out of examination of the MySQLdb driver, which uses >> the format paramstyle. As far as I can tell, that parameter style gives you >> printf-style formatting, nothing more, nothing less. It doesn't add quotes >> around substituted values, doesn't escape special characters, doesn't turn >> None into NULL in the resulting query string, etc. > >You are probably looking at an old version. As somebody already stated, the >latest MySQLdb does proper binding, where you don't need to do any quoting. Actually, it turned out to be complete stupidity on my part. Jon Ribbens pointed out to me what I was doing wrong; all works as it should. Thanks, all. From jtt@hnc.com Mon Nov 27 17:57:01 2000 From: jtt@hnc.com (Turney, James) Date: Mon, 27 Nov 2000 09:57:01 -0800 Subject: [DB-SIG] newbee help with DCOracle Message-ID: <72A838A51366D211B3B30008C7F4D363052132AE@pchnc.hnc.com> I have managed to get DCOracle1.3.2 to compile and link on a Solaris 2.6 system using Oracle 7.3.4. The test program that comes with DCOracle seems to open a connection to the database. When I attempt to use any of the methods Connection objects are supposed to support I get a message similar to the following: "Connection object has no attribute". For example, if the following is run from the python interpreter import Buffer, oci_, sys print 'Import succeeded' dbc=oci_.Connect('dbuserid/dbpassword) dbc.close() The execution of the dbc.close() always results in the following message: AttributeError: 'Connection' object has no attribute 'close' I have placed the DCOracle package (including the shared objects created) in my path and LD_LIBRARY_PATH. Any help would be appreciated. jtt@hnc.com From Andreas Jung Mon Nov 27 18:02:34 2000 From: Andreas Jung (Andreas Jung) Date: Mon, 27 Nov 2000 19:02:34 +0100 Subject: [DB-SIG] newbee help with DCOracle In-Reply-To: <72A838A51366D211B3B30008C7F4D363052132AE@pchnc.hnc.com>; from jtt@hnc.com on Mon, Nov 27, 2000 at 09:57:01AM -0800 References: <72A838A51366D211B3B30008C7F4D363052132AE@pchnc.hnc.com> Message-ID: <20001127190234.A12560@yetix.sz-sb.de> On Mon, Nov 27, 2000 at 09:57:01AM -0800, Turney, James wrote: > I have managed to get DCOracle1.3.2 to compile and link on a Solaris 2.6 > system using Oracle 7.3.4. > The test program that comes with DCOracle seems to open a connection to the > database. When I attempt to use any of the methods Connection objects are > supposed to support I get a message similar to the following: "Connection > object has no attribute". > For example, if the following is run from the python interpreter > > > import Buffer, oci_, sys > > print 'Import succeeded' > > dbc=oci_.Connect('dbuserid/dbpassword) > > dbc.close() > > The execution of the dbc.close() always results in the following message: > AttributeError: 'Connection' object has no attribute 'close' > > I have placed the DCOracle package (including the shared objects created) in > my path and LD_LIBRARY_PATH. > Please read the docs. It is not suggested to use directly the oci_ module. Instead import the DCOracle package - this should fix your problem. Cheers, Andreas From jtt@hnc.com Mon Nov 27 20:46:14 2000 From: jtt@hnc.com (Turney, James) Date: Mon, 27 Nov 2000 12:46:14 -0800 Subject: [DB-SIG] newbee help with DCOracle Message-ID: <72A838A51366D211B3B30008C7F4D36305268E0D@pchnc.hnc.com> Thanks for quick response.... By the way I not a developer so any extra details are appreciated. I think my problem is that I don't have the DCOracle package installed correclty? I copied the .so's created by the make to the dcoracle directory as specified in the README.txt in src dir. I added the dcoracle directory to my Unix path and my pythonpath. What else do I need to be able to import dcoracle? Thanks again, Jim Turney jtt@hnc.com -----Original Message----- From: Andreas Jung [SMTP:andreas@andreas-jung.com] Sent: Monday, November 27, 2000 10:03 AM To: Turney, James Cc: db-sig@python.org Subject: Re: [DB-SIG] newbee help with DCOracle On Mon, Nov 27, 2000 at 09:57:01AM -0800, Turney, James wrote: > I have managed to get DCOracle1.3.2 to compile and link on a Solaris 2.6 > system using Oracle 7.3.4. > The test program that comes with DCOracle seems to open a connection to the > database. When I attempt to use any of the methods Connection objects are > supposed to support I get a message similar to the following: "Connection > object has no attribute". > For example, if the following is run from the python interpreter > > > import Buffer, oci_, sys > > print 'Import succeeded' > > dbc=oci_.Connect('dbuserid/dbpassword) > > dbc.close() > > The execution of the dbc.close() always results in the following message: > AttributeError: 'Connection' object has no attribute 'close' > > I have placed the DCOracle package (including the shared objects created) in > my path and LD_LIBRARY_PATH. > Please read the docs. It is not suggested to use directly the oci_ module. Instead import the DCOracle package - this should fix your problem. Cheers, Andreas From jtt@hnc.com Mon Nov 27 22:09:56 2000 From: jtt@hnc.com (Turney, James) Date: Mon, 27 Nov 2000 14:09:56 -0800 Subject: FW: [DB-SIG] newbee help with DCOracle - Problem solved. Message-ID: <72A838A51366D211B3B30008C7F4D36305269106@pchnc.hnc.com> After doing some searching of comp.lang.python I came upon several other people who had the same issue. The problem was solved by correctly adding the dcoracle directory to my PYTHONPATH and making sure the .so's created by the DCOracle make were also in the dcoracle directory. The confusion was caused by the fact the test program for DCOracle does not import the DCOracle module (as recommend) but directly imports the OCI_ and Buffer modules. It appears that most people (me included) used the test program a starting point. Unfortunately, it was bad example. Thanks to those people who responded. With your help I was able to figure it out. Thanks. Jim Turney jtt@hnc.com -----Original Message----- From: Turney, James Sent: Monday, November 27, 2000 12:45 PM To: Subject: RE: [DB-SIG] newbee help with DCOracle Thanks for quick response.... By the way I not a developer so any extra details are appreciated. I think my problem is that I don't have the DCOracle package installed correclty? I copied the .so's created by the make to the dcoracle directory as specified in the README.txt in src dir. I added the dcoracle directory to my Unix path and my pythonpath. What else do I need to be able to import dcoracle? Thanks again, Jim Turney jtt@hnc.com -----Original Message----- From: Andreas Jung [SMTP:andreas@andreas-jung.com] Sent: Monday, November 27, 2000 10:03 AM To: Turney, James Cc: db-sig@python.org Subject: Re: [DB-SIG] newbee help with DCOracle On Mon, Nov 27, 2000 at 09:57:01AM -0800, Turney, James wrote: > I have managed to get DCOracle1.3.2 to compile and link on a Solaris 2.6 > system using Oracle 7.3.4. > The test program that comes with DCOracle seems to open a connection to the > database. When I attempt to use any of the methods Connection objects are > supposed to support I get a message similar to the following: "Connection > object has no attribute". > For example, if the following is run from the python interpreter > > > import Buffer, oci_, sys > > print 'Import succeeded' > > dbc=oci_.Connect('dbuserid/dbpassword) > > dbc.close() > > The execution of the dbc.close() always results in the following message: > AttributeError: 'Connection' object has no attribute 'close' > > I have placed the DCOracle package (including the shared objects created) in > my path and LD_LIBRARY_PATH. > Please read the docs. It is not suggested to use directly the oci_ module. Instead import the DCOracle package - this should fix your problem. Cheers, Andreas From Andreas Jung Tue Nov 28 07:32:26 2000 From: Andreas Jung (Andreas Jung) Date: Tue, 28 Nov 2000 08:32:26 +0100 Subject: [DB-SIG] newbee help with DCOracle In-Reply-To: <72A838A51366D211B3B30008C7F4D36305268E0D@pchnc.hnc.com>; from jtt@hnc.com on Mon, Nov 27, 2000 at 12:46:14PM -0800 References: <72A838A51366D211B3B30008C7F4D36305268E0D@pchnc.hnc.com> Message-ID: <20001128083226.A30254@yetix.sz-sb.de> On Mon, Nov 27, 2000 at 12:46:14PM -0800, Turney, James wrote: > Thanks for quick response.... > By the way I not a developer so any extra details are appreciated. > > I think my problem is that I don't have the DCOracle package installed > correclty? I copied the .so's created by the make to the dcoracle > directory as specified in the README.txt in src dir. I added the dcoracle > directory to my Unix path and my pythonpath. > What else do I need to be able to import dcoracle? The package contains a subdirectory "DCOracle". The .so files should be placed inside this directory. The DCOracle directory itself should be anywhere in your PYTHONPATH or in the site-packages directory. This should work. Andreas From randy@rebeccaphillips.com Thu Nov 30 22:03:31 2000 From: randy@rebeccaphillips.com (Randy) Date: Thu, 30 Nov 2000 17:03:31 -0500 Subject: [DB-SIG] ANN: Public domain Python schema hypermap maker Message-ID: <200011302203.eAUM3Vu30087@server1400.net> All, Python Hyperschema is an open source public domain project that creates useful and really cool HTML hypermaps from SQL database schema, consisting of two small SQL files and one Python (or C) source code file. The generated HTML pages have mousover data displays for all foreign keys, hyperlinked to the foreign key tables, as well as a hyperlinked list of all foreign keys pointing to each table and a master index of all tables. The URL is http://hyperschema.sourceforge.net. Randy Phillips From jonan-lists-python-db@callisia.com Thu Nov 30 23:38:02 2000 From: jonan-lists-python-db@callisia.com (jonan-lists-python-db@callisia.com) Date: Thu, 30 Nov 2000 18:38:02 -0500 Subject: [DB-SIG] Dumping Table Schema Message-ID: <20001130183802.A2079@sindri.callisia.com> Hello, Is there any way to dump the schema of a table ? I am aware of cursor.description however this only works for a result set. I would like to know the schema regardless of data content. Can this been done in a portable way ? Right now I'm just using cur.execute("describe tablename") for MySQL but a portable way would be better. Have a nice day. -- -Jonan Santiago -Callisia Communications -http://www.callisia.com