From ChuckEsterbrook@yahoo.com Mon Dec 3 05:27:41 2001 From: ChuckEsterbrook@yahoo.com (Chuck Esterbrook) Date: Sun, 2 Dec 2001 21:27:41 -0800 Subject: [DB-SIG] [ANNOUNCE] MiddleKit 0.2 (Webware for Python 0.6) Message-ID: <20011203052742.ERIY485.femail3.sdc1.sfba.home.com@there> Webware is a suite of Python packages for developing object-oriented, web-based applications. The suite includes a package named MiddleKit which provides: * automatic SQL generation for * creation of a database * managing objects at runtime * additional type checking of attributes * powerful delete rules to avoid errors and provide automatic behavior (deny, detach and cascade) This is all driven off an object model that describes a class hierarchy and attributes. You can also use the object model for other purposes such as generating reports, sample data, forms, etc. MiddleKit documentation can be browsed online at: http://webware.sourceforge.net/Webware/MiddleKit/Docs/ The Webware home page is at: http://webware.sourceforge.net/ You can download Webware 0.6 directly from: http://prdownloads.sourceforge.net/webware/Webware-0.6.tar.gz From Cary.Coulter@argushealth.com Mon Dec 3 19:27:44 2001 From: Cary.Coulter@argushealth.com (Coulter, Cary) Date: Mon, 3 Dec 2001 13:27:44 -0600 Subject: [DB-SIG] IBM DB2 interface module DB2.py Message-ID: <6F2BF2187534624FADC9DD0E7D5C9DB7573383@ARG-MXSVS01.corp.argushealth.com> I'm running DB2 on AIX. Using the DB2.py (v0.99) module. I'm able to fetch some data but am having a problem. Sample code: import DB2 conn =3D DB2Connection(dsn=3D'xxx', uid=3D'xxx', pwd=3D'xxx') curs =3D conn.cursor() # 1 ret =3D curs.execute("SELECT * from TABLE") data =3D curs.fetchall() # 2 ret =3D curs.execute("SELECT * from TABLE WHERE ID LIKE 'abc%'") data =3D curs.fetchall() # 3 ret =3D curs.execute("SELECT ID, NAME from TABLE") data =3D curs.fetchall() The first 2 select/fetchall's work. 'data' is a list of tuples containing the row data. Dumping curs.description shows a tuple of tuples with all of the columns and their attributes. The third execute/fetchall doesn't work completely. 'data' is a empty list ([] rather than None) but curs.description contains a tuple of tuples for the 2 columns specified. Any idea why #3 won't work or something to look at?? I can put some debug code in the _db2_module.c code and log stuff to disk, but first I'm looking for something simpler than learning the low level interface to DB2. Thanks in advance. Cary Coulter Lead System Programmer 816-435-2425 Argus Health Systems, Inc. From jayhawks@netsgo.com Thu Dec 6 04:34:58 2001 From: jayhawks@netsgo.com (jayhawks) Date: Thu, 6 Dec 2001 13:34:58 +0900 Subject: [DB-SIG] [Q] how to Informix + mxODBC and how to get SQLCODE ? Message-ID: <009a01c17e0f$5d18cc40$0ed5eacb@kdh.co.kr> This is a multi-part message in MIME format. ------=_NextPart_000_0097_01C17E5A.CC678FA0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SEk/IA0KDQpJJ20gc3RydWdnbGUgdG8gdXNlIG14T0RCQyB3aXRoIEluZm9ybWl4IERhdGFiYXNl IG9uIFJlZEhhdDYuMiBMaW51eCAoa2VybmVsIDIuNC42IHZlcnNpb24gLCBweXRob24gMi4wKQ0K DQpFdmVyeSBUcmlhbCBoYXMgZmFpbGVkLg0KDQpJIGRpZCBmb2xsd29pbmcgc3RlcHM6DQoNCmFs cmVhZHkgaW5zdGFsbGVkIEluZm9ybWl4IENsaWVudCBTREsgLCBlZGl0ZWQgb2RiY2luc3QuaW5p ICwgb2RiYy5pbmkgIC4NCg0KMS4gaW5zdGFsbCAgcHl0aG9uMi4wIGFscmVhZHkgDQoNCjIuIGlu c3RhbGwgaU9EQkMgMy4wLjUucnBtIA0KDQozLiBpbnN0YWxsICBteE9EQkNfYmFzZV9weXRob24y LjAucnBtIA0KDQo0LiBpbnN0YWxsbCBteE9EQkNfY29tbWVyY2lhbF9weXRob24yLjAucnBtIA0K DQo1LiBlZGl0IFNldHVwIGZpbGUgZm9yIEluZm9ybWl4IExEX0xJQlJBUllfUEFUSCBzIGluIG14 T0RCQ19jb21tZXJjaWFsIERJUi9teC9PREJDL0luZm9ybWl4IERJUi4NCg0KNi4gcnVuICJtYWtl IC1mIE1ha2VmaWxlLnByZS5pbiBib290IiAgaW4gc2FtZSBESVIgLCBydW4gIm1ha2UiDQoNCiAg IEkgZ290IGVycm9ycyB3aXRoIGZpbGVzICggbXhPREJDLmMgYW5kIGFub3RoZXIgZmlsZSApIC4g VGhpcyBlcnJvcyBmb3IgVU5JQ09ERSBTdXBvcnQgIC4NCg0KICAgVGh1cyBJIHJlbW92ZWQgYXJl YSBmb3IgVU5JQ09ERSBzdXBwb3J0IG9uIHRob3NlIHNvdXJjZXMgLGFuZCB0aGVuIHJlcnVuICJt YWtlIi4NCg0KNy4gcnVuICJweXRob24gc2V0dXAucHkgaW5zdGFsbCIgaW4gbXhPREJDX2NvbW1l cmNpYWwgRElSIC4NCg0KOC4gVGVzdGluZyB3aXRoIHRlc3QucHkgDQoNCiAgICAgV2hlbiBpICBy dW4gInB5dGhvbiB0ZXN0LnB5IiAgYW5kICB0aGVuICBpIGlucHV0IHZhbHVlcyBzdWNoIGFzICBE U04vVUlEL1BXRCAsDQoNCiAgICAgaXQgc3RvcHMgcnVubmluZyAgYW5kIGRvZXMgbm90IGFueXRo aW5nIGkgdGhpbmsuDQoNCiAgICAgYnV0IGluIGhvc3QgKCB0aGVyZSBpcyAgaW5mb3JtaXggZGF0 YWJhc2UgcnVubmluZykgIGkgY2hlY2sgbmV0d29yayBzdGF0dXMgd2l0aCBuZXRzdGF0IGNvbW1h bmQgLA0KDQogICAgIGl0IHNob3dzIG1lIHRoYXQgIGNvbm5lY3Rpb24gaXMgRVNUQUJMSVNIRUQg Lg0KDQpPaG0sIEkgc3VjY2VlZGVkIGluIHRlc3Rpbmcgb2RiYyBjb25uZWN0aW9uIGFuZCAgZXhl Y3V0aW5nIHF1ZXJ5IHdpdGggdGhlIG9kYmN0ZXN0IG9mIGlvZGJjIHV0aWxpdGllcyAuDQoNCkkg cmVmZXJlbmNlIHRoaXMgVVJMICJodHRwOi8vd3d3LmxlbWJ1cmcuY29tL2ZpbGVzL3B5dGhvbi9t eE9EQkMuaHRtbCAgIg0KDQpBbnlvbmUgd2hvIHN1Y2NlZWQgPyANCg0KQ2FuIEkgZ2V0IG1vcmUg YW5kIG1vcmUgZGV0YWlsIGluZm9ybWF0aW9uIGFib3V0IHVzaW5nIE9EQkMgd2l0aCBteE9EQkMg KyBJbmZvcm1peCArIHB5dGhvbjIuMCBvbiBsaW51eD8NCg0KDQoNClRoYW5rcyAuDQoNCg0KDQo= ------=_NextPart_000_0097_01C17E5A.CC678FA0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPFA+SEk/ IA0KPFA+SSdtIHN0cnVnZ2xlIHRvIHVzZSBteE9EQkMgd2l0aCBJbmZvcm1peCBEYXRhYmFzZSBv biBSZWRIYXQ2LjIgTGludXggKGtlcm5lbCANCjIuNC42IHZlcnNpb24gLCBweXRob24gMi4wKQ0K PFA+RXZlcnkgVHJpYWwgaGFzIGZhaWxlZC4NCjxQPkkmbmJzcDtkaWQmbmJzcDtmb2xsd29pbmcg c3RlcHM6DQo8UD5hbHJlYWR5IGluc3RhbGxlZCBJbmZvcm1peCBDbGllbnQgU0RLICwgZWRpdGVk IG9kYmNpbnN0LmluaSAsIG9kYmMuaW5pJm5ic3A7IA0KLg0KPFA+MS4gaW5zdGFsbCZuYnNwOyBw eXRob24yLjAgYWxyZWFkeSANCjxQPjIuIGluc3RhbGwgaU9EQkMgMy4wLjUucnBtIA0KPFA+My4m bmJzcDtpbnN0YWxsICZuYnNwO214T0RCQ19iYXNlX3B5dGhvbjIuMC5ycG0mbmJzcDsNCjxQPjQu Jm5ic3A7aW5zdGFsbGwgbXhPREJDX2NvbW1lcmNpYWxfcHl0aG9uMi4wLnJwbSANCjxQPjUuIGVk aXQgU2V0dXAgZmlsZSBmb3IgSW5mb3JtaXggTERfTElCUkFSWV9QQVRIIHMgaW4gbXhPREJDX2Nv bW1lcmNpYWwgDQpESVIvbXgvT0RCQy9JbmZvcm1peCBESVIuDQo8UD42LiBydW4gIm1ha2UgLWYg TWFrZWZpbGUucHJlLmluIGJvb3QiJm5ic3A7IGluIHNhbWUgRElSICwgcnVuICJtYWtlIg0KPFA+ Jm5ic3A7Jm5ic3A7Jm5ic3A7SSBnb3QgZXJyb3JzIHdpdGggZmlsZXMgKCBteE9EQkMuYyBhbmQg YW5vdGhlciBmaWxlICkgLiANClRoaXMgZXJyb3MgZm9yIFVOSUNPREUgU3Vwb3J0Jm5ic3A7IC4N CjxQPiZuYnNwOyZuYnNwOyBUaHVzIEkgcmVtb3ZlZCBhcmVhIGZvciBVTklDT0RFIHN1cHBvcnQg b24gdGhvc2Ugc291cmNlcyAsYW5kIA0KdGhlbiByZXJ1biAibWFrZSIuDQo8UD43LiBydW4gInB5 dGhvbiBzZXR1cC5weSBpbnN0YWxsIiBpbiBteE9EQkNfY29tbWVyY2lhbCBESVIgLg0KPFA+OC4g VGVzdGluZyB3aXRoIHRlc3QucHkgDQo8UD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2hlbiZu YnNwO2kgJm5ic3A7cnVuICJweXRob24gdGVzdC5weSImbmJzcDsgYW5kIA0KJm5ic3A7dGhlbiZu YnNwOyBpIGlucHV0IHZhbHVlcyZuYnNwO3N1Y2ggYXMgJm5ic3A7RFNOL1VJRC9QV0QgLA0KPFA+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGl0IHN0b3BzIHJ1bm5pbmcgJm5ic3A7YW5kIGRvZXMg bm90IGFueXRoaW5nIGkgDQp0aGluay4NCjxQPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBidXQg aW4gaG9zdCAoJm5ic3A7dGhlcmUgaXMgJm5ic3A7aW5mb3JtaXggZGF0YWJhc2UgDQpydW5uaW5n KSZuYnNwOyBpIGNoZWNrIG5ldHdvcmsgc3RhdHVzIHdpdGggbmV0c3RhdCBjb21tYW5kICwNCjxQ PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpdCBzaG93cyBtZSB0aGF0ICZuYnNwO2Nvbm5lY3Rp b24gaXMgDQpFU1RBQkxJU0hFRCZuYnNwOy4NCjxQPk9obSwgSSBzdWNjZWVkZWQgaW4gdGVzdGlu ZyBvZGJjIGNvbm5lY3Rpb24gYW5kJm5ic3A7IGV4ZWN1dGluZyBxdWVyeSB3aXRoIA0KdGhlIG9k YmN0ZXN0IG9mIGlvZGJjIHV0aWxpdGllcyZuYnNwOy4NCjxQPkkgcmVmZXJlbmNlIHRoaXMgVVJM ICI8QSANCmhyZWY9Imh0dHA6Ly93d3cubGVtYnVyZy5jb20vZmlsZXMvcHl0aG9uL214T0RCQy5o dG1sIj5odHRwOi8vd3d3LmxlbWJ1cmcuY29tL2ZpbGVzL3B5dGhvbi9teE9EQkMuaHRtbDwvQT4m bmJzcDsgDQoiDQo8UD5BbnlvbmUgd2hvIHN1Y2NlZWQgPyANCjxQPkNhbiBJIGdldCBtb3JlIGFu ZCBtb3JlIGRldGFpbCBpbmZvcm1hdGlvbiBhYm91dCB1c2luZyZuYnNwO09EQkMgd2l0aCBteE9E QkMgDQorIEluZm9ybWl4ICsgcHl0aG9uMi4wIG9uIGxpbnV4Pw0KPFA+Jm5ic3A7DQo8UD5UaGFu a3MgLg0KPFA+Jm5ic3A7PC9QPjwhLS1DTEFTUz0iaW5kZW50Ii0tPjwvRk9OVD48L0RJVj48L0JP RFk+PC9IVE1MPg0K ------=_NextPart_000_0097_01C17E5A.CC678FA0-- From mal@lemburg.com Thu Dec 6 15:53:29 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Dec 2001 16:53:29 +0100 Subject: [DB-SIG] [Q] how to Informix + mxODBC and how to get SQLCODE ? References: <009a01c17e0f$5d18cc40$0ed5eacb@kdh.co.kr> Message-ID: <3C0F9479.6868219@lemburg.com> > jayhawks wrote: > > HI? > > I'm struggle to use mxODBC with Informix Database on RedHat6.2 Linux > (kernel 2.4.6 version , python 2.0) > > Every Trial has failed. > > I did follwoing steps: > > already installed Informix Client SDK , edited odbcinst.ini , > odbc.ini . > > 1. install python2.0 already > > 2. install iODBC 3.0.5.rpm > > 3. install mxODBC_base_python2.0.rpm > > 4. installl mxODBC_commercial_python2.0.rpm > > 5. edit Setup file for Informix LD_LIBRARY_PATH s in mxODBC_commercial > DIR/mx/ODBC/Informix DIR. There's no need for this: you should connect to Informix using iODBC. > 6. run "make -f Makefile.pre.in boot" in same DIR , run "make" Same here. If you've installed the RPMs you don't need to run any make or python setup.py install. > I got errors with files ( mxODBC.c and another file ) . This erros > for UNICODE Suport . Make sure you use the latest egenix-mx-commercial release. > Thus I removed area for UNICODE support on those sources ,and then > rerun "make". > > 7. run "python setup.py install" in mxODBC_commercial DIR . Again, this should not be necessary. > 8. Testing with test.py > > When i run "python test.py" and then i input values such as > DSN/UID/PWD , > > it stops running and does not anything i think. > > but in host ( there is informix database running) i check > network status with netstat command , > > it shows me that connection is ESTABLISHED . > > Ohm, I succeeded in testing odbc connection and executing query with > the odbctest of iodbc utilities . > > I reference this URL "http://www.lemburg.com/files/python/mxODBC.html > " > > Anyone who succeed ? > > Can I get more and more detail information about using ODBC with > mxODBC + Informix + python2.0 on linux? If you can get iODBC to connect, mxODBC shouldn't have a problem connecting to the database as well. The connection goes like this: mx.iODBC.DriverConnect("DSN=...;UID=...;PWD=...") | (dynamic linking) v libiodbc.so | (dynamic linking) v Informix ODBC driver (e.g. libsomeodbcdriver.so) | (possibly via a network) v Informix Database Hope this helps, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From vranicar@fnal.gov Thu Dec 6 16:12:53 2001 From: vranicar@fnal.gov (Matthew Vranicar) Date: Thu, 06 Dec 2001 10:12:53 -0600 Subject: [DB-SIG] Re: DB-SIG digest, Vol 1 #530 - 1 msg References: Message-ID: <3C0F9905.E5DAA6F7@fnal.gov> Cary, What if you did not just reuse the same cursor, but used individual cursor objects for each of your queries? Or at least closed/opened the cursor again. Would this help? Like this: import DB2 conn = DB2Connection(dsn='xxx', uid='xxx', pwd='xxx') # 1 curs = conn.cursor() ret = curs.execute("SELECT * from TABLE") data = curs.fetchall() curs.close() # 2 curs = conn.cursor() ret = curs.execute("SELECT * from TABLE WHERE ID LIKE 'abc%'") data = curs.fetchall() curs.close() # 3 curs = conn.cursor() ret = curs.execute("SELECT ID, NAME from TABLE") data = curs.fetchall() curs.close() db-sig-request@python.org wrote: > Send DB-SIG mailing list submissions to > db-sig@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/db-sig > or, via email, send a message with subject or body 'help' to > db-sig-request@python.org > > You can reach the person managing the list at > db-sig-admin@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DB-SIG digest..." > > ------------------------------------------------------------------------ > Today's Topics: > > 1. IBM DB2 interface module DB2.py (Coulter, Cary) > > ------------------------------------------------------------------------ > > Subject: [DB-SIG] IBM DB2 interface module DB2.py > Date: Mon, 3 Dec 2001 13:27:44 -0600 > From: "Coulter, Cary" > To: > > I'm running DB2 on AIX. Using the DB2.py (v0.99) module. I'm able to > fetch some data but am having a problem. > > Sample code: > > import DB2 > > conn = DB2Connection(dsn='xxx', uid='xxx', pwd='xxx') > > curs = conn.cursor() > > # 1 > ret = curs.execute("SELECT * from TABLE") > data = curs.fetchall() > > # 2 > ret = curs.execute("SELECT * from TABLE WHERE ID LIKE 'abc%'") > data = curs.fetchall() > > # 3 > ret = curs.execute("SELECT ID, NAME from TABLE") > data = curs.fetchall() > > The first 2 select/fetchall's work. 'data' is a list of tuples > containing the row data. Dumping curs.description shows a tuple of > tuples with all of the columns and their attributes. > > The third execute/fetchall doesn't work completely. 'data' is a empty > list ([] rather than None) but curs.description contains a tuple of > tuples for the 2 columns specified. > > Any idea why #3 won't work or something to look at?? I can put some > debug code in the _db2_module.c code and log stuff to disk, but first > I'm looking for something simpler than learning the low level interface > to DB2. > > Thanks in advance. > > Cary Coulter > Lead System Programmer > 816-435-2425 > Argus Health Systems, Inc. From kimtitu@yahoo.com Fri Dec 7 01:56:12 2001 From: kimtitu@yahoo.com (Titu Kim) Date: Thu, 6 Dec 2001 17:56:12 -0800 (PST) Subject: [DB-SIG] Consistent connection to Oracle Message-ID: <20011207015612.34191.qmail@web14702.mail.yahoo.com> I am wondering how can i keep using the same connection to Oracle Database through DCOracle2. In my cgi script, i do ############################## connection = DCOracle2.connect(dsn="username/password@db") c = connection.cursor() ############################## at the beginning of the script and i close the connection at the end of the script using connection.close(). How can i place this connection so it is reusable without reconnecting for every request? Thanks. Kim Titu __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com From jno@glasnet.ru Fri Dec 7 06:45:55 2001 From: jno@glasnet.ru (Eugene V . Dvurechenski) Date: Fri, 7 Dec 2001 09:45:55 +0300 Subject: [DB-SIG] Consistent connection to Oracle In-Reply-To: <20011207015612.34191.qmail@web14702.mail.yahoo.com>; from kimtitu@yahoo.com on Thu, Dec 06, 2001 at 05:56:12PM -0800 References: <20011207015612.34191.qmail@web14702.mail.yahoo.com> Message-ID: <20011207094555.U5690@glas.net> no way in plain vanilla CGI technology (do you need it for web?). you may check something like PCGI instead. another way is to use something like medusa's asyncore to build a connection sharing server then feed all the queries via this shared connection[s] pool. NB: there are good chances that you'll not be able to use _threading_ with Oracle clinet libs. hence, synchronous approach looks much better. "forking" approach will not work as expected either. On Thu, Dec 06, 2001 at 05:56:12PM -0800, Titu Kim wrote: > I am wondering how can i keep using the same > connection to Oracle Database through DCOracle2. In my > cgi script, i do > ############################## > connection = > DCOracle2.connect(dsn="username/password@db") > c = connection.cursor() > ############################## > at the beginning of the script and i close the > connection at the end of the script using > connection.close(). How can i place this connection so > it is reusable without reconnecting for every request? -- SY, jno (PRIVATE PERSON) [ http://www.glasnet.ru/~jno ] a TeleRoss techie [ http://www.aviation.ru/ ] If God meant man to fly, He'd have given him more money. From j.andrusaitis@konts.lv Fri Dec 7 08:28:58 2001 From: j.andrusaitis@konts.lv (Jekabs Andrushaitis) Date: Fri, 7 Dec 2001 10:28:58 +0200 Subject: [DB-SIG] Consistent connection to Oracle In-Reply-To: <20011207094555.U5690@glas.net> Message-ID: <000501c17ef9$3792d250$262a949f@konts.lv> Regular Python CGI's is not the best solution around - it is SLOW for Apache (whatever server you use:) to load Python interpreter for every request. Personally I have fallen in love with mod_python (can also be used to emulate regular Pytho CGI behaviour). mod_python links Python to Apache at start time, so Python interpreter is always present. This speeds ups request processing, since interpreter does not need to be loaded for each request, but also gives nice feature of saving Python objects globally which will persist between connections. This can be used for persistant DB connection for example. jEECHA From jno@glasnet.ru Fri Dec 7 13:59:17 2001 From: jno@glasnet.ru (Eugene V . Dvurechenski) Date: Fri, 7 Dec 2001 16:59:17 +0300 Subject: [DB-SIG] Consistent connection to Oracle In-Reply-To: <000501c17ef9$3792d250$262a949f@konts.lv>; from j.andrusaitis@konts.lv on Fri, Dec 07, 2001 at 10:28:58AM +0200 References: <20011207094555.U5690@glas.net> <000501c17ef9$3792d250$262a949f@konts.lv> Message-ID: <20011207165917.W5690@glas.net> On Fri, Dec 07, 2001 at 10:28:58AM +0200, Jekabs Andrushaitis wrote: > nice feature of saving Python objects globally which will persist between > connections. > This can be used for persistant DB connection for example. most likely this will crash the application to core dump :-( connection object is not "simple" - it relays on Oracle client libs which are not aware of persistance, etc... -- SY, jno (PRIVATE PERSON) [ http://www.glasnet.ru/~jno ] a TeleRoss techie [ http://www.aviation.ru/ ] If God meant man to fly, He'd have given him more money. From jno@glasnet.ru Fri Dec 7 14:07:43 2001 From: jno@glasnet.ru (Eugene V . Dvurechenski) Date: Fri, 7 Dec 2001 17:07:43 +0300 Subject: [DB-SIG] Consistent connection to Oracle In-Reply-To: <3C10C282.9020306@zope.com>; from matt@zope.com on Fri, Dec 07, 2001 at 08:22:10AM -0500 References: <20011207015612.34191.qmail@web14702.mail.yahoo.com> <20011207094555.U5690@glas.net> <3C10C282.9020306@zope.com> Message-ID: <20011207170743.Y5690@glas.net> On Fri, Dec 07, 2001 at 08:22:10AM -0500, Matthew T. Kromer wrote: > > Actually, the oracle client libs are fully thread enabled. Most stable > is the latest releases, particularly for Linux -- 8.1.7 or 9i. maybe. we are still with 8.1.6 on HP-UX... negative experience obtained since 7.3.1 on Solaris. -- SY, jno (PRIVATE PERSON) [ http://www.glasnet.ru/~jno ] a TeleRoss techie [ http://www.aviation.ru/ ] If God meant man to fly, He'd have given him more money. From Greg.Lindstrom@acxiom.com Fri Dec 7 17:56:23 2001 From: Greg.Lindstrom@acxiom.com (Lindstrom Greg - glinds) Date: Fri, 7 Dec 2001 11:56:23 -0600 Subject: [DB-SIG] Date/Time in Gadfly Message-ID: Greetings- I am new to the database aspect of Python and have just downloaded Gadfly to get me started. Does Gadfly support Date/Time constructs (or is that a SQL issue)? Thanks! Greg Lindstrom Acxiom Corporation, mail: CWY10011149 InfoBase Products Development office: (501) 342-1626 301 Industrial Blvd, Conway, AR, 72032 fax: (501) 336-3911 email: Greg.Lindstrom@acxiom.com "Programming requires discipline. Period. If you're depending on a compiler to catch sloppy thinking, then you've got trouble." John Roth From matt@zope.com Fri Dec 7 13:22:10 2001 From: matt@zope.com (Matthew T. Kromer) Date: Fri, 07 Dec 2001 08:22:10 -0500 Subject: [DB-SIG] Consistent connection to Oracle References: <20011207015612.34191.qmail@web14702.mail.yahoo.com> <20011207094555.U5690@glas.net> Message-ID: <3C10C282.9020306@zope.com> Eugene V . Dvurechenski wrote: >no way in plain vanilla CGI technology (do you need it for web?). >you may check something like PCGI instead. > >another way is to use something like medusa's asyncore >to build a connection sharing server then feed all the >queries via this shared connection[s] pool. > >NB: there are good chances that you'll not be able to use >_threading_ with Oracle clinet libs. hence, synchronous >approach looks much better. "forking" approach will not >work as expected either. > Actually, the oracle client libs are fully thread enabled. Most stable is the latest releases, particularly for Linux -- 8.1.7 or 9i. From wichert@wiggy.net Fri Dec 7 21:18:43 2001 From: wichert@wiggy.net (Wichert Akkerman) Date: Fri, 7 Dec 2001 22:18:43 +0100 Subject: [DB-SIG] looking for transaction documentations Message-ID: <20011207211843.GX5946@wiggy.net> I can't seem to find in the DB API 2.0 spec how to transactions. The text does mention them, but it is silent on how to start, abort or end them. Can someone shed some light on this? Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From bkline@rksystems.com Sat Dec 8 01:17:10 2001 From: bkline@rksystems.com (Bob Kline) Date: Fri, 7 Dec 2001 20:17:10 -0500 (EST) Subject: [DB-SIG] looking for transaction documentations In-Reply-To: <20011207211843.GX5946@wiggy.net> Message-ID: On Fri, 7 Dec 2001, Wichert Akkerman wrote: > I can't seem to find in the DB API 2.0 spec how to transactions. The > text does mention them, but it is silent on how to start, abort or > end them. > > Can someone shed some light on this? Sure. This API follows the ANSI SQL standard in its approach to transactions, which are always implicit. Look at the docs for commit() and rollback(). Think of it as working in a world where 'autocommit' is always off. -- Bob Kline mailto:bkline@rksystems.com http://www.rksystems.com From andy47@halfcooked.com Mon Dec 10 04:02:09 2001 From: andy47@halfcooked.com (Andy Todd) Date: Mon, 10 Dec 2001 15:02:09 +1100 Subject: [DB-SIG] Date/Time in Gadfly References: Message-ID: <3C1433C1.8080202@halfcooked.com> Greg, Sadly, no. Although gadfly is based on the SQL standard supported by ODBC 2.0 (which I think is, in turn, based on ANSI SQL 92) it doesn't support a native date construct. If you look in the file sqlgram.py (line 94-97) you will see that the only reserved words for data types are INTEGER, FLOAT and VARCHAR. So, if dates are important to you there are really only two choices; store them as numbers and write your own conversion routines or upgrade to a different database system. Well, actually there is a third option - add a date datatype (such as mxDATETIME) to gadfly and earn the gratitude of an entire community ;-) In all other respects gadfly is a great database engine. Its a definite improvement over shelve/pickle and it is really easy to include with your own applications so that you are not reliant on non Python software. Lindstrom Greg - glinds wrote: > Greetings- > > I am new to the database aspect of Python and have just downloaded Gadfly to > get me started. Does Gadfly support Date/Time constructs (or is that a SQL > issue)? > > Thanks! > > Greg Lindstrom > Acxiom Corporation, mail: CWY10011149 > InfoBase Products Development office: (501) 342-1626 > 301 Industrial Blvd, Conway, AR, 72032 fax: (501) 336-3911 > email: Greg.Lindstrom@acxiom.com > > "Programming requires discipline. Period. If you're depending on a compiler > to catch sloppy thinking, then you've got trouble." John Roth > > > HTH, Andy -- ----------------------------------------------------------------------- From the desk of Andrew J Todd esq. "Another year older, still no wiser." - Me, on my birthday From dario@ita.chalmers.se Mon Dec 10 09:16:33 2001 From: dario@ita.chalmers.se (=?iso-8859-1?Q?Dario_Lopez-K=E4sten?=) Date: Mon, 10 Dec 2001 10:16:33 +0100 Subject: [DB-SIG] Consistent connection to Oracle References: <20011207015612.34191.qmail@web14702.mail.yahoo.com> <20011207094555.U5690@glas.net> <3C10C282.9020306@zope.com> <20011207170743.Y5690@glas.net> Message-ID: <009001c1815b$5cb705b0$33de1081@ita.chalmers.se> From: "Eugene V . Dvurechenski" > On Fri, Dec 07, 2001 at 08:22:10AM -0500, Matthew T. Kromer wrote: > > > > Actually, the oracle client libs are fully thread enabled. Most stable > > is the latest releases, particularly for Linux -- 8.1.7 or 9i. > > maybe. > we are still with 8.1.6 on HP-UX... > negative experience obtained since 7.3.1 on Solaris. there are several people having negative experiences with the combination solaris, threads and python on the zope@zope.org lists. The problems are not zope-related nor are they linked to DB-adapters in general, but seem to be more apparent with zope, since it totally relies on threads, which of course trigger the problem more often. We are trying to pin down the problem, but so far have yet to find what exactly it is that cause these problems... of course it there are bugs in DCO2, that won't help either... :P /dario From dario@ita.chalmers.se Mon Dec 10 09:26:15 2001 From: dario@ita.chalmers.se (=?iso-8859-1?Q?Dario_Lopez-K=E4sten?=) Date: Mon, 10 Dec 2001 10:26:15 +0100 Subject: [DB-SIG] Consistent connection to Oracle References: <20011207015612.34191.qmail@web14702.mail.yahoo.com> <20011207094555.U5690@glas.net> <3C10C282.9020306@zope.com> <20011207170743.Y5690@glas.net> Message-ID: <009f01c1815c$b782c6e0$33de1081@ita.chalmers.se> From: "Eugene V . Dvurechenski" > > maybe. > we are still with 8.1.6 on HP-UX... > negative experience obtained since 7.3.1 on Solaris. forgot to add this: in general, Oracle 8i versions prior to 8.1.7 suck, so in general I would strongly suggest that you upgrade (I know, I know, it's not just a matter of "uppgrading when every new release comes out", but if you can upgrade, do it). We run Oracle 8.1.6 and 8.1.7 on Solaris and 8.1.7, and 8.1.7. /dario From dario@ita.chalmers.se Mon Dec 10 10:20:49 2001 From: dario@ita.chalmers.se (=?iso-8859-1?Q?Dario_Lopez-K=E4sten?=) Date: Mon, 10 Dec 2001 11:20:49 +0100 Subject: [DB-SIG] Consistent connection to Oracle References: <20011207015612.34191.qmail@web14702.mail.yahoo.com> <20011207094555.U5690@glas.net> <3C10C282.9020306@zope.com> <20011207170743.Y5690@glas.net> <009f01c1815c$b782c6e0$33de1081@ita.chalmers.se> Message-ID: <00a601c18164$56b26890$33de1081@ita.chalmers.se> > We run Oracle 8.1.6 and 8.1.7 on Solaris and 8.1.7, and 8.1.7. ~~~~~~~~~~~~~~~~~~~~ uh, dunno what happened here. Ignore that part :-) /dario From j.andrusaitis@konts.lv Mon Dec 10 10:37:01 2001 From: j.andrusaitis@konts.lv (Jekabs Andrushaitis) Date: Mon, 10 Dec 2001 12:37:01 +0200 Subject: [DB-SIG] Consistent connection to Oracle In-Reply-To: <20011210132957.A5690@glas.net> Message-ID: <001001c18166$9ae34f00$262a949f@konts.lv> I noticed that I hit Reply, not Reply All button only AFTER I did send my reply, and I was too lazy to repost the message to the list :) Sorry > it's ok and looks obviuos to me ;-) > the only my point is [possible] quirks in _oracle's_ own libs. > and these quirks are not reproducable on _all_ platforms. I have been using Oracle along with Python in another application (not Web related), but the environment for it is quite similar to that of Apache+Python+Oracle - I have a TUXEDO server application (TUXEDO is a transaction monitor from BEA, but thats not the important thing), which is written in C and has linked with Python and interprets some parts of application which are written in Python. I use pre-historic non-DBAPI 2 compliant Python Oracle module with my own patches (this is the reason I cannot yet use DCOracle :( ) with persistant connection to DB. This scenario is working fine in 7.3, 8.1.6, 8.1.7, 9i under Solaris and HP-UX, as well as 8.1.7 and 9i under Linux. (For Oracle 8.1.7 I have tried threaded mode too, and for most part it does work - on Linux Python sometimes runs itself into problems with threads, but doesnt seem it has something to do with Oracle) > i'm now not using mod_python. > i use php to write oracle apps... well, this might not be the best choice. > btw, could you please compare the performance of mod_python versus php? I dont have running PHP here right now, but back when I visually compared the performance PHP was doing work done a little faster, however I decided to sacrifice that little for all the features Python gives - heavy Object-Oriented dynamic content mostly :) > is there a patch for that? It can be made by yourself without much trouble - just look at the Python libs of mod_python, and you will find comments like - comment this out to prevent module reloading (btw, not loading modules for each request gives about 300% performance boost, and is best for production site where you do not change Python code of server regularly). jEECHA From fog@mixadlive.com Mon Dec 10 10:48:28 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: 10 Dec 2001 11:48:28 +0100 Subject: [DB-SIG] looking for transaction documentations In-Reply-To: References: Message-ID: <1007981309.9907.0.camel@nenya> On Sat, 2001-12-08 at 02:17, Bob Kline wrote: > On Fri, 7 Dec 2001, Wichert Akkerman wrote: >=20 > > I can't seem to find in the DB API 2.0 spec how to transactions. The > > text does mention them, but it is silent on how to start, abort or > > end them. > > > > Can someone shed some light on this? >=20 > Sure. This API follows the ANSI SQL standard in its approach to > transactions, which are always implicit. Look at the docs for commit() > and rollback(). Think of it as working in a world where 'autocommit' is > always off. just noting that at least half of the db adapters out there offer an autocommit mode where you can roll your own transactions sending "BEGIN", "COMMIT", etc. queries. --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Qu'est ce que la folie? Juste un sentiment de libert=E9 si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra From Greg.Lindstrom@acxiom.com Tue Dec 11 13:34:00 2001 From: Greg.Lindstrom@acxiom.com (Lindstrom Greg - glinds) Date: Tue, 11 Dec 2001 07:34:00 -0600 Subject: [DB-SIG] Date/Time in MySQL Message-ID: Is everyone else getting the huge amount of Spam from this list? I thought this list was moderated. But I digress.... I am now using mySQL as my database so I have access to Date/Time data. I have created a database and have access methods, but would like to know how to create a Select to fetch all dates in a given range. I have tried just about everything I can think of. Could one of you show me how to do this? Thanks! Greg Lindstrom Acxiom Corporation, mail: CWY10011149 InfoBase Products Development office: (501) 342-1626 301 Industrial Blvd, Conway, AR, 72032 fax: (501) 336-3911 email: Greg.Lindstrom@acxiom.com "Programming requires discipline. Period. If you're depending on a compiler to catch sloppy thinking, then you've got trouble." John Roth From bkline@rksystems.com Tue Dec 11 13:50:44 2001 From: bkline@rksystems.com (Bob Kline) Date: Tue, 11 Dec 2001 08:50:44 -0500 (EST) Subject: [OT] Re: [DB-SIG] Date/Time in MySQL In-Reply-To: Message-ID: On Tue, 11 Dec 2001, Lindstrom Greg - glinds wrote: > Is everyone else getting the huge amount of Spam from this list? I > thought this list was moderated. I doubt that the list is moderated, as this is the wrong list for the question below (there are mailing lists and newsgroups for both MySQL and for general SQL questions). > I am now using mySQL as my database so I have access to Date/Time > data. I have created a database and have access methods, but would > like to know how to create a Select to fetch all dates in a given > range. I have tried just about everything I can think of. Could > one of you show me how to do this? http://www.mysql.com/documentation/mysql/bychapter/manual_Tutorial.html#Selecting_rows -- Bob Kline mailto:bkline@rksystems.com http://www.rksystems.com From david@dataovation.com Tue Dec 11 16:26:52 2001 From: david@dataovation.com (David A McInnis) Date: Tue, 11 Dec 2001 08:26:52 -0800 Subject: [DB-SIG] Date/Time in MySQL In-Reply-To: Message-ID: That depends what you are trying to do. This could be more a function of MySQL than Python. For example if you want to select a range of dates that is between today and a week ago you would do: SELECT . . . . WHERE datefield > DATE_SUB(NOW(), INTERVAL 1 WEEK) and datefield <= NOW() or SELECT . . . . WHERE datefield > DATE_SUB(NOW(), INTERVAL 7 DAY) and datefield <= NOW() or to select around a specific date, try date = '2001-12-02' """SELECT . . . . WHERE datefield > DATE_SUB(%s, INTERVAL 7 DAY) and datefield <= %s""", (date, date) You can also use CURDATE() which is actually better if you are using dates than NOW() as NOW() returns the time and CURDATE returns just the date. David -----Original Message----- From: db-sig-admin@python.org [mailto:db-sig-admin@python.org]On Behalf Of Lindstrom Greg - glinds Sent: Tuesday, December 11, 2001 5:34 AM To: 'db-sig@python.org' Subject: [DB-SIG] Date/Time in MySQL Is everyone else getting the huge amount of Spam from this list? I thought this list was moderated. But I digress.... I am now using mySQL as my database so I have access to Date/Time data. I have created a database and have access methods, but would like to know how to create a Select to fetch all dates in a given range. I have tried just about everything I can think of. Could one of you show me how to do this? Thanks! Greg Lindstrom Acxiom Corporation, mail: CWY10011149 InfoBase Products Development office: (501) 342-1626 301 Industrial Blvd, Conway, AR, 72032 fax: (501) 336-3911 email: Greg.Lindstrom@acxiom.com "Programming requires discipline. Period. If you're depending on a compiler to catch sloppy thinking, then you've got trouble." John Roth _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig From Cary.Coulter@argushealth.com Tue Dec 11 19:04:47 2001 From: Cary.Coulter@argushealth.com (Coulter, Cary) Date: Tue, 11 Dec 2001 13:04:47 -0600 Subject: [DB-SIG] RE: DB-SIG digest, Vol 1 #530 - 1 msg Message-ID: <6F2BF2187534624FADC9DD0E7D5C9DB701519E37@ARG-MXSVS01.corp.argushealth.com> No change. -----Original Message----- From: Matthew Vranicar [mailto:vranicar@fnal.gov]=20 Sent: Thursday, December 06, 2001 10:13 AM To: db-sig@python.org; Coulter, Cary Subject: Re: DB-SIG digest, Vol 1 #530 - 1 msg Cary, What if you did not just reuse the same cursor, but used individual cursor objects for each of your queries? Or at least closed/opened the cursor again. Would this help? Like this: import DB2 conn =3D DB2Connection(dsn=3D'xxx', uid=3D'xxx', pwd=3D'xxx') # 1 curs =3D conn.cursor() ret =3D curs.execute("SELECT * from TABLE") data =3D curs.fetchall() curs.close() # 2 curs =3D conn.cursor() ret =3D curs.execute("SELECT * from TABLE WHERE ID LIKE 'abc%'") data =3D curs.fetchall() curs.close() # 3 curs =3D conn.cursor() ret =3D curs.execute("SELECT ID, NAME from TABLE") data =3D curs.fetchall() curs.close() db-sig-request@python.org wrote: > Send DB-SIG mailing list submissions to > db-sig@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/db-sig > or, via email, send a message with subject or body 'help' to > db-sig-request@python.org > > You can reach the person managing the list at > db-sig-admin@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DB-SIG digest..." > > ------------------------------------------------------------------------ > Today's Topics: > > 1. IBM DB2 interface module DB2.py (Coulter, Cary) > > ------------------------------------------------------------------------ > > Subject: [DB-SIG] IBM DB2 interface module DB2.py > Date: Mon, 3 Dec 2001 13:27:44 -0600 > From: "Coulter, Cary" > To: > > I'm running DB2 on AIX. Using the DB2.py (v0.99) module. I'm able to > fetch some data but am having a problem. > > Sample code: > > import DB2 > > conn =3D DB2Connection(dsn=3D'xxx', uid=3D'xxx', pwd=3D'xxx') > > curs =3D conn.cursor() > > # 1 > ret =3D curs.execute("SELECT * from TABLE") > data =3D curs.fetchall() > > # 2 > ret =3D curs.execute("SELECT * from TABLE WHERE ID LIKE 'abc%'") > data =3D curs.fetchall() > > # 3 > ret =3D curs.execute("SELECT ID, NAME from TABLE") > data =3D curs.fetchall() > > The first 2 select/fetchall's work. 'data' is a list of tuples > containing the row data. Dumping curs.description shows a tuple of > tuples with all of the columns and their attributes. > > The third execute/fetchall doesn't work completely. 'data' is a empty > list ([] rather than None) but curs.description contains a tuple of > tuples for the 2 columns specified. > > Any idea why #3 won't work or something to look at?? I can put some > debug code in the _db2_module.c code and log stuff to disk, but first > I'm looking for something simpler than learning the low level interface > to DB2. > > Thanks in advance. > > Cary Coulter > Lead System Programmer > 816-435-2425 > Argus Health Systems, Inc. From andy@dustman.net Tue Dec 11 20:29:56 2001 From: andy@dustman.net (Andy Dustman) Date: 11 Dec 2001 15:29:56 -0500 Subject: [DB-SIG] Date/Time in MySQL In-Reply-To: References: Message-ID: <1008102596.1712.5.camel@chef.comstar.net> On Tue, 2001-12-11 at 08:34, Lindstrom Greg - glinds wrote: > I am now using mySQL as my database so I have access to Date/Time data. I > have created a database and have access methods, but would like to know how > to create a Select to fetch all dates in a given range. I have tried just > about everything I can think of. Could one of you show me how to do this? One thing to watch out for with MySQLdb is due to the fact that it uses format codes (i.e. %s) for parameter placeholders. Because of this, if you need a literal % in your SQL, you need to double it (%%). This isn't really documented, and I should fix that... David's example looks okay, and you don't need to %% there because it is doing parameter substitution. But supposing you used the LIKE operator against a literal string in your query, and you are using % as the wildcard match, that % you would have to double. If you are passing in a string literal with a % as a parameter, don't worry about it, because it can't be interpreted as a format code. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From vranicar@fnal.gov Thu Dec 13 17:16:18 2001 From: vranicar@fnal.gov (Matthew Vranicar) Date: Thu, 13 Dec 2001 11:16:18 -0600 Subject: [DB-SIG] Re: DB-SIG digest, Vol 1 #530 - 1 msg References: <6F2BF2187534624FADC9DD0E7D5C9DB701519E37@ARG-MXSVS01.corp.argushealth.com> Message-ID: <3C18E262.F074B2D7@fnal.gov> If that did not work, the only other thing you can try before you will have to debug the source is to use different cursor names for each execution. I do not think that will help either, but it may be worth a try. import DB2 conn = DB2Connection(dsn='xxx', uid='xxx', pwd='xxx') # 1 cur1 = conn.cursor() ret = cur1.execute("SELECT * from TABLE") data = cur1.fetchall() cur1.close() # 2 cur2 = conn.cursor() ret = cur2.execute("SELECT * from TABLE WHERE ID LIKE 'abc%'") data = cur2.fetchall() cur2.close() # 3 cur3 = conn.cursor() ret = cur3.execute("SELECT ID, NAME from TABLE") data = cur3.fetchall() cur3.close() "Coulter, Cary" wrote: > No change. > > -----Original Message----- > From: Matthew Vranicar [mailto:vranicar@fnal.gov] > Sent: Thursday, December 06, 2001 10:13 AM > To: db-sig@python.org; Coulter, Cary > Subject: Re: DB-SIG digest, Vol 1 #530 - 1 msg > > Cary, > What if you did not just reuse the same cursor, but used individual > cursor > objects for each of your queries? Or at least closed/opened the cursor > again. Would this help? > > Like this: > > import DB2 > conn = DB2Connection(dsn='xxx', uid='xxx', pwd='xxx') > > # 1 > curs = conn.cursor() > ret = curs.execute("SELECT * from TABLE") > data = curs.fetchall() > curs.close() > > # 2 > curs = conn.cursor() > ret = curs.execute("SELECT * from TABLE WHERE ID LIKE 'abc%'") > data = curs.fetchall() > curs.close() > > # 3 > curs = conn.cursor() > ret = curs.execute("SELECT ID, NAME from TABLE") > data = curs.fetchall() > curs.close() > > db-sig-request@python.org wrote: > > > Send DB-SIG mailing list submissions to > > db-sig@python.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://mail.python.org/mailman/listinfo/db-sig > > or, via email, send a message with subject or body 'help' to > > db-sig-request@python.org > > > > You can reach the person managing the list at > > db-sig-admin@python.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of DB-SIG digest..." > > > > > ------------------------------------------------------------------------ > > Today's Topics: > > > > 1. IBM DB2 interface module DB2.py (Coulter, Cary) > > > > > ------------------------------------------------------------------------ > > > > Subject: [DB-SIG] IBM DB2 interface module DB2.py > > Date: Mon, 3 Dec 2001 13:27:44 -0600 > > From: "Coulter, Cary" > > To: > > > > I'm running DB2 on AIX. Using the DB2.py (v0.99) module. I'm able to > > fetch some data but am having a problem. > > > > Sample code: > > > > import DB2 > > > > conn = DB2Connection(dsn='xxx', uid='xxx', pwd='xxx') > > > > curs = conn.cursor() > > > > # 1 > > ret = curs.execute("SELECT * from TABLE") > > data = curs.fetchall() > > > > # 2 > > ret = curs.execute("SELECT * from TABLE WHERE ID LIKE 'abc%'") > > data = curs.fetchall() > > > > # 3 > > ret = curs.execute("SELECT ID, NAME from TABLE") > > data = curs.fetchall() > > > > The first 2 select/fetchall's work. 'data' is a list of tuples > > containing the row data. Dumping curs.description shows a tuple of > > tuples with all of the columns and their attributes. > > > > The third execute/fetchall doesn't work completely. 'data' is a empty > > list ([] rather than None) but curs.description contains a tuple of > > tuples for the 2 columns specified. > > > > Any idea why #3 won't work or something to look at?? I can put some > > debug code in the _db2_module.c code and log stuff to disk, but first > > I'm looking for something simpler than learning the low level > interface > > to DB2. > > > > Thanks in advance. > > > > Cary Coulter > > Lead System Programmer > > 816-435-2425 > > Argus Health Systems, Inc. From j.andrusaitis@konts.lv Fri Dec 14 07:28:24 2001 From: j.andrusaitis@konts.lv (Jekabs Andrushaitis) Date: Fri, 14 Dec 2001 09:28:24 +0200 Subject: [DB-SIG] SQL statement parse for Oracle In-Reply-To: <1007981309.9907.0.camel@nenya> Message-ID: <000001c18470$eaa96c60$262a949f@konts.lv> In the Oracle world SQL statement parsing can take considerable CPU/Block IO for complex statements. Well, I am using pre-historic Oracle DB module (looks like some OLD DCOracle to me:), however I did not see anything related to this in DBAPI too. What I am talking about is API to allow to parse statement for a cursor (for Oracle OCI it is done by 'oparse' calls) without executing it. It could be used to speed up things in situation where same statement has to be executed several times with different bind variables for example. Or when you want application uses persistand DB connection and you can create several cursors for each operation you need to perform thus eliminating cost of parsing each statement over and over again... >From DB-API's point of view it could be Python methods for cursor object: dbc.parse('some statement here') dbc.executeparsed([some bind variables here]) This can be a very useful feature for DBAPI to have, since in case of Oracle and complex statements executed many times it can make the difference visible. I have made made these patches for my OLD OLD Oracle module (sadly I have to stick with it for now cause of other patches weve made in it - Python DB connection object creation from embedded SQL connections, various memory leak fixes which were critical in the environment I am using this module etc:)... Maybe I am totally missing something about DBAPI spec, and if above described features do exist in the spec, then ignore this silly mail :) Also, I am not aware of RDBMS supporting parsing without executing, but Oracle certainly is one of those :) Jekabs From jno@glasnet.ru Fri Dec 14 09:28:12 2001 From: jno@glasnet.ru (Eugene V . Dvurechenski) Date: Fri, 14 Dec 2001 12:28:12 +0300 Subject: [DB-SIG] SQL statement parse for Oracle In-Reply-To: <000001c18470$eaa96c60$262a949f@konts.lv>; from j.andrusaitis@konts.lv on Fri, Dec 14, 2001 at 09:28:24AM +0200 References: <1007981309.9907.0.camel@nenya> <000001c18470$eaa96c60$262a949f@konts.lv> Message-ID: <20011214122812.K5690@glas.net> btw, Oracle should not reparse a statement if it matches anything that was already parsed. hence, if you use bind variables you have good chances to get your statement cached and avoid extra times to parse it again. well, in case of "assembled" statements you may loos such a feature... On Fri, Dec 14, 2001 at 09:28:24AM +0200, Jekabs Andrushaitis wrote: > In the Oracle world SQL statement parsing can take considerable CPU/Block IO > for complex statements. Well, I am using pre-historic Oracle DB module > (looks like > some OLD DCOracle to me:), however I did not see anything related to this in > DBAPI too. > What I am talking about is API to allow to parse statement for a cursor (for > Oracle > OCI it is done by 'oparse' calls) without executing it. It could be used to > speed > up things in situation where same statement has to be executed several times > with different bind variables for example. Or when you want application uses > persistand DB connection and you can create several cursors for each > operation > you need to perform thus eliminating cost of parsing each statement over and > over > again... > > >From DB-API's point of view it could be Python methods for cursor object: > dbc.parse('some statement here') > dbc.executeparsed([some bind variables here]) > > This can be a very useful feature for DBAPI to have, since in case of Oracle > and > complex statements executed many times it can make the difference visible. > > I have made made these patches for my OLD OLD Oracle module (sadly I have > to stick with it for now cause of other patches weve made in it - Python DB > connection > object creation from embedded SQL connections, various memory leak fixes > which > were critical in the environment I am using this module etc:)... > > Maybe I am totally missing something about DBAPI spec, and if above > described > features do exist in the spec, then ignore this silly mail :) > > Also, I am not aware of RDBMS supporting parsing without executing, but > Oracle > certainly is one of those :) -- SY, jno (PRIVATE PERSON) [ http://www.glasnet.ru/~jno ] a TeleRoss techie [ http://www.aviation.ru/ ] If God meant man to fly, He'd have given him more money. From mal@lemburg.com Fri Dec 14 09:53:30 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 14 Dec 2001 10:53:30 +0100 Subject: [DB-SIG] SQL statement parse for Oracle References: <000001c18470$eaa96c60$262a949f@konts.lv> Message-ID: <3C19CC1A.103B8FFB@lemburg.com> Jekabs Andrushaitis wrote: > > In the Oracle world SQL statement parsing can take considerable CPU/Block IO > for complex statements. > ... > What I am talking about is API to allow to parse statement for a cursor (for > Oracle > OCI it is done by 'oparse' calls) without executing it. It could be used to > speed > up things in situation where same statement has to be executed several times > with different bind variables for example. This is already possible using the .execute() command cache which is described in the DB API. > Or when you want application uses > persistand DB connection and you can create several cursors for each > operation > you need to perform thus eliminating cost of parsing each statement over and > over > again... See above. The only problem is that you have to execute the statement at least once to get it prepared on the cursor. This isn't much of a problem though if you wrap the DB API cursor objects in more elaborate Python objects (for abstraction purposes or to extend them with new features you need). The reason for not putting this into the DB API is that some DBs may not be able to separate the prepare and the execute steps, e.g. some ODBC drivers only pretend to prepare the statement -- the actual parsing etc. still takes place at .execute() time. Perhaps I should add a .prepare() method to the set of standard DB API extensions though ?! Here's what I have in mxODBC: .prepare(operation) Prepare a database operation (query or command) statement for later execution and set cursor.command. To execute a prepared statement, pass cursor.statement to one of the .executeXXX() methods. Return values are not defined. and .command Provides access to the last prepared or executed SQL command available through the cursor. If no such command is available, None is returned. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From daniel.dittmar@sap.com Fri Dec 14 11:19:40 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Fri, 14 Dec 2001 12:19:40 +0100 Subject: [DB-SIG] SQL statement parse for Oracle Message-ID: Jekabs Andrushaitis wrote: > > In the Oracle world SQL statement parsing can take > considerable CPU/Block IO > > for complex statements. > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Perhaps I should add a .prepare() method to the set of standard > DB API extensions though ?! Would it be useful to give an option to the cursor () method that statements for this cursor should be cached by the connection? - at least with connection pools, it is much easier to have the connection object handle the statement cache instead of managing a pool of PreparedStatements - I'm somewhat reluctant to cache ALL statements as some programmers tend to build complete INSERT statements rather than using parameters. The current strategy with the SAP DB implementation is to reuse the parse information if the SQL string hasn't changed since the last execute (), statements without parameters are executed without a prepare step. This works reasonably well for the sane case of using one cursor for only one purpose, but fails in the case of connection pooling. Daniel -- Daniel Dittmar SAP DB, SAP Labs Berlin daniel.dittmar@sap.com http://www.sapdb.org/ From mal@lemburg.com Fri Dec 14 11:39:30 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 14 Dec 2001 12:39:30 +0100 Subject: [DB-SIG] SQL statement parse for Oracle References: Message-ID: <3C19E4F2.F7F13B8E@lemburg.com> "Dittmar, Daniel" wrote: > > Jekabs Andrushaitis wrote: > > > In the Oracle world SQL statement parsing can take > > considerable CPU/Block IO > > > for complex statements. > > > From: M.-A. Lemburg [mailto:mal@lemburg.com] > > Perhaps I should add a .prepare() method to the set of standard > > DB API extensions though ?! > > Would it be useful to give an option to the cursor () method that statements > for this cursor should be cached by the connection? > - at least with connection pools, it is much easier to have the connection > object handle the statement cache instead of managing a pool of > PreparedStatements > - I'm somewhat reluctant to cache ALL statements as some programmers tend to > build complete INSERT statements rather than using parameters. > > The current strategy with the SAP DB implementation is to reuse the parse > information if the SQL string hasn't changed since the last execute (), > statements without parameters are executed without a prepare step. This > works reasonably well for the sane case of using one cursor for only one > purpose, but fails in the case of connection pooling. I'd suggest to add a writeable attribute .cacheable to your implementation... I don't think that adding all this to the DB API spec will really help since even the .execute() statement caching is optional. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From j.andrusaitis@konts.lv Fri Dec 14 11:33:39 2001 From: j.andrusaitis@konts.lv (Jekabs Andrushaitis) Date: Fri, 14 Dec 2001 13:33:39 +0200 Subject: [DB-SIG] SQL statement parse for Oracle In-Reply-To: Message-ID: <000b01c18493$2d822f50$262a949f@konts.lv> > The current strategy with the SAP DB implementation is to reuse the parse > information if the SQL string hasn't changed since the last execute (), > statements without parameters are executed without a prepare step. This > works reasonably well for the sane case of using one cursor for only one > purpose, but fails in the case of connection pooling. Hmm, actually this is a reasonable solution too for DB backends which support parsed statements for their cursors. Little overhead of comparing 2 strings (SQL statements) is probably way less than asking DB to parse the statement anew. I also try to use seperate cursors for commonly performed statements, only time I dont use that is for statements which execute rarely, and adding extra cursors certainly does not pay back in that case. DB connection pooling sadly disallows this feature (XA interface in fact too), and the fate of statements in that case is solely in hands of DB parser :) Also, I might add that people who do not use bind variables (well, there are DB engines which dont supoprt them, sadly) are potentially shooting theirselves in foot. They just end up writing utilities to work around reserved characters, and in the end there still might be a chance of a security problem due to user passing unexpected strings as variables causing execution of arbitrary SQL statements etc... So basically this is a BAD IDEA... Jekabs P.S. Sorry for starting this thread, I hope it does not turn into SPAM soon! From TKeating@origin.ea.com Fri Dec 14 17:16:52 2001 From: TKeating@origin.ea.com (Keating, Tim) Date: Fri, 14 Dec 2001 11:16:52 -0600 Subject: [DB-SIG] SQL statement parse for Oracle Message-ID: <2292DBED5A978A498EABCCE95524499E0281D900@osi-postal.osi.ad.ea.com> This seems like engineering a solution for a non-existent problem. You can achieve the same effect by simply making the statement a stored procedure, which every database programmer worth his salt knows how to do. Just my $0.02. TK > -----Original Message----- > From: Jekabs Andrushaitis [mailto:j.andrusaitis@konts.lv] > Sent: Friday, December 14, 2001 1:28 AM > To: 'Python DB-SIG Mailing List' > Subject: [DB-SIG] SQL statement parse for Oracle > > > In the Oracle world SQL statement parsing can take > considerable CPU/Block IO > for complex statements. Well, I am using pre-historic Oracle DB module > (looks like > some OLD DCOracle to me:), however I did not see anything > related to this in > DBAPI too. > What I am talking about is API to allow to parse statement > for a cursor (for > Oracle > OCI it is done by 'oparse' calls) without executing it. It > could be used to > speed > up things in situation where same statement has to be > executed several times > with different bind variables for example. Or when you want > application uses > persistand DB connection and you can create several cursors for each > operation > you need to perform thus eliminating cost of parsing each > statement over and > over > again... > > From DB-API's point of view it could be Python methods for > cursor object: > dbc.parse('some statement here') > dbc.executeparsed([some bind variables here]) > > This can be a very useful feature for DBAPI to have, since in > case of Oracle > and > complex statements executed many times it can make the > difference visible. > > I have made made these patches for my OLD OLD Oracle module > (sadly I have > to stick with it for now cause of other patches weve made in > it - Python DB > connection > object creation from embedded SQL connections, various memory > leak fixes > which > were critical in the environment I am using this module etc:)... > > Maybe I am totally missing something about DBAPI spec, and if above > described > features do exist in the spec, then ignore this silly mail :) > > Also, I am not aware of RDBMS supporting parsing without > executing, but > Oracle > certainly is one of those :) > > Jekabs > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > From matt@zope.com Fri Dec 14 13:51:44 2001 From: matt@zope.com (Matthew T. Kromer) Date: Fri, 14 Dec 2001 08:51:44 -0500 Subject: [DB-SIG] SQL statement parse for Oracle References: <000001c18470$eaa96c60$262a949f@konts.lv> Message-ID: <3C1A03F0.6020707@zope.com> For what it's worth, DCOracle2 has two ways to do that -- first, if a Cursor sees an identical (string eqivalent) command go through execute() again, it doesn't call prepare on it, since it was the last command prepared. Secondly, DCOracle 1 had a cursor.prepare(statement) which returned a cursor with a prepared statement on it. DCOracle2 sort-of supports this, in that it takes a prepare method on a db and sniffs it a bit to see if it looks like a statement, or an instruction to do a two-phase commit prepare. If it looks like a statement, it returns a cursor with that statement prepared on it, which can then be passed a None statement to use the previously prepared one (ie None acts as a "use last statement" statement). DCOracle 1 code used this to do things like stmt = db.prepare(statement) stmt.execute(arg1=1,arg2=2) etc which will still function properly with DCOracle2. Since DCOracle2 is based on OCI8 though, if you're still using an Oracle 7 system you'd have to upgrade your client libs. Jekabs Andrushaitis wrote: >In the Oracle world SQL statement parsing can take considerable CPU/Block IO >for complex statements. Well, I am using pre-historic Oracle DB module >(looks like >some OLD DCOracle to me:), however I did not see anything related to this in >DBAPI too. >What I am talking about is API to allow to parse statement for a cursor (for >Oracle >OCI it is done by 'oparse' calls) without executing it. It could be used to >speed >up things in situation where same statement has to be executed several times >with different bind variables for example. Or when you want application uses >persistand DB connection and you can create several cursors for each >operation >you need to perform thus eliminating cost of parsing each statement over and >over >again... > >>From DB-API's point of view it could be Python methods for cursor object: > dbc.parse('some statement here') > dbc.executeparsed([some bind variables here]) > >This can be a very useful feature for DBAPI to have, since in case of Oracle >and >complex statements executed many times it can make the difference visible. > >I have made made these patches for my OLD OLD Oracle module (sadly I have >to stick with it for now cause of other patches weve made in it - Python DB >connection >object creation from embedded SQL connections, various memory leak fixes >which >were critical in the environment I am using this module etc:)... > >Maybe I am totally missing something about DBAPI spec, and if above >described >features do exist in the spec, then ignore this silly mail :) > >Also, I am not aware of RDBMS supporting parsing without executing, but >Oracle >certainly is one of those :) > >Jekabs > > >_______________________________________________ >DB-SIG maillist - DB-SIG@python.org >http://mail.python.org/mailman/listinfo/db-sig > From anthony@computronix.com Fri Dec 14 17:19:55 2001 From: anthony@computronix.com (Anthony Tuininga) Date: Fri, 14 Dec 2001 10:19:55 -0700 Subject: [DB-SIG] SQL statement parse for Oracle References: <000001c18470$eaa96c60$262a949f@konts.lv> Message-ID: <3C1A34BB.1020800@computronix.com> I have done something similar with cx_Oracle, my own Oracle Python module. But I have simply stated that if the statement passed to execute is None, do not do the parse, simply the bind. The method described here is a little more obvious but I chose the first to avoid muddying the waters with respect to the Python DB API. I would support such a change to the API (as an option, since calling execute will still work). Anthony Jekabs Andrushaitis wrote: >In the Oracle world SQL statement parsing can take considerable >CPU/Block IO >for complex statements. Well, I am using pre-historic Oracle DB module >(looks like >some OLD DCOracle to me:), however I did not see anything related to >this in >DBAPI too. >What I am talking about is API to allow to parse statement for a cursor >(for >Oracle >OCI it is done by 'oparse' calls) without executing it. It could be used >to >speed >up things in situation where same statement has to be executed several >times >with different bind variables for example. Or when you want application >uses >persistand DB connection and you can create several cursors for each >operation >you need to perform thus eliminating cost of parsing each statement over >and >over >again... > >From DB-API's point of view it could be Python methods for cursor >object: > dbc.parse('some statement here') > dbc.executeparsed([some bind variables here]) > >This can be a very useful feature for DBAPI to have, since in case of >Oracle >and >complex statements executed many times it can make the difference >visible. > >I have made made these patches for my OLD OLD Oracle module (sadly I >have >to stick with it for now cause of other patches weve made in it - Python >DB >connection >object creation from embedded SQL connections, various memory leak fixes >which >were critical in the environment I am using this module etc:)... > >Maybe I am totally missing something about DBAPI spec, and if above >described >features do exist in the spec, then ignore this silly mail :) > >Also, I am not aware of RDBMS supporting parsing without executing, but >Oracle >certainly is one of those :) > >Jekabs > > >_______________________________________________ >DB-SIG maillist - DB-SIG@python.org >http://mail.python.org/mailman/listinfo/db-sig > From anthony@computronix.com Fri Dec 14 17:27:42 2001 From: anthony@computronix.com (Anthony Tuininga) Date: Fri, 14 Dec 2001 10:27:42 -0700 Subject: [DB-SIG] SQL statement parse for Oracle References: <20011214122812.K5690@glas.net> Message-ID: <3C1A368E.5040508@computronix.com> No, the reparse does take place. It may find something in the cache which reduces the cost considerably, but it does not eliminate it like avoiding the call to parse would in fact do. The only other possibility I can think of, is to keep a copy of the string that was last parsed around and then perform a compare internally to determine if the string matches and if so, don't bother with the parse. That method, however, adds overhead to all calls whereas the introduction of a parse() and executeparsed() method eliminates the problem in the cases that matter (high number of iterations executed). Anthony Eugene V . Dvurechenski wrote: >btw, Oracle should not reparse a statement if it matches anything >that was already parsed. hence, if you use bind variables you have >good chances to get your statement cached and avoid extra times >to parse it again. well, in case of "assembled" statements you >may loos such a feature... > >On Fri, Dec 14, 2001 at 09:28:24AM +0200, Jekabs Andrushaitis wrote: > >>In the Oracle world SQL statement parsing can take considerable >> >CPU/Block IO > >>for complex statements. Well, I am using pre-historic Oracle DB module >>(looks like >>some OLD DCOracle to me:), however I did not see anything related to >> >this in > >>DBAPI too. >>What I am talking about is API to allow to parse statement for a >> >cursor (for > >>Oracle >>OCI it is done by 'oparse' calls) without executing it. It could be >> >used to > >>speed >>up things in situation where same statement has to be executed several >> >times > >>with different bind variables for example. Or when you want >> >application uses > >>persistand DB connection and you can create several cursors for each >>operation >>you need to perform thus eliminating cost of parsing each statement >> >over and > >>over >>again... >> >>>From DB-API's point of view it could be Python methods for cursor >> >object: > >> dbc.parse('some statement here') >> dbc.executeparsed([some bind variables here]) >> >>This can be a very useful feature for DBAPI to have, since in case of >> >Oracle > >>and >>complex statements executed many times it can make the difference >> >visible. > >>I have made made these patches for my OLD OLD Oracle module (sadly I >> >have > >>to stick with it for now cause of other patches weve made in it - >> >Python DB > >>connection >>object creation from embedded SQL connections, various memory leak >> >fixes > >>which >>were critical in the environment I am using this module etc:)... >> >>Maybe I am totally missing something about DBAPI spec, and if above >>described >>features do exist in the spec, then ignore this silly mail :) >> >>Also, I am not aware of RDBMS supporting parsing without executing, >> >but > >>Oracle >>certainly is one of those :) >> > From mal@lemburg.com Fri Dec 14 17:37:19 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 14 Dec 2001 18:37:19 +0100 Subject: [DB-SIG] SQL statement parse for Oracle References: <3C19CC1A.103B8FFB@lemburg.com> <3C1A376C.3030605@computronix.com> Message-ID: <3C1A38CF.72CFFA54@lemburg.com> Anthony Tuininga wrote: > > Ok, that sounds reasonable. I have one question, though. Is the last > ".command" meant to be ".statement"? I called it .command because the SQL you execute is not always a statement. > In other words, is the statement > that is prepared stored with the cursor and then also passed to the > execute function? Like this? > > cursor.prepare("SQL") > cursor.execute(cursor.statement, parameters) Yes, that's the idea. This is needed in order to make the whole thing compatible to the .executexxx() methods. > If that is what is intended, I can live with that as there is a simple > pointer comparison in order to determine if the statement ought to be > parsed or not. Right, that's the idea -- you sort of reuse the .execute() caching idea for separating the two steps. > M.-A. Lemburg wrote: > >Perhaps I should add a .prepare() method to the set of standard > >DB API extensions though ?! > > > >Here's what I have in mxODBC: > > > > .prepare(operation) > > > > Prepare a database operation (query or command) statement for > > later execution and set cursor.command. > > To execute a prepared statement, pass > > cursor.statement to one of the .executeXXX() methods. > > Return values are not defined. > > > >and > > > > .command > > > > Provides access to the last prepared or executed SQL command > > available through the cursor. If no such command is available, > > None is returned. > > -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From TKeating@origin.ea.com Fri Dec 14 18:19:15 2001 From: TKeating@origin.ea.com (Keating, Tim) Date: Fri, 14 Dec 2001 12:19:15 -0600 Subject: [DB-SIG] SQL statement parse for Oracle Message-ID: <2292DBED5A978A498EABCCE95524499E0281D905@osi-postal.osi.ad.ea.com> No condescension intended, it just seems to me that if the client starts doing SQL parses and caching the results, you're shifting a chunk of functionality from the server to the client. It's also way more client than (IMHO) most people need, and the desired result (minimizing SQL parses) can be achieved with an existing piece of functionality. I also suspect that this would be a lot harder to do than it sounds like on paper. TK > -----Original Message----- > From: Anthony Tuininga [mailto:anthony@computronix.com] > Sent: Friday, December 14, 2001 12:02 PM > To: Keating, Tim > Cc: 'j.andrusaitis@konts.lv'; 'Python DB-SIG Mailing List' > Subject: Re: [DB-SIG] SQL statement parse for Oracle > > > Ok, that seems rather condescending.... Or it might just be > me..... :-) > > The problem with creating a stored procedure is that you lose > complete > control. If you wanted to, for example, print something to stdout for > each row processed (or set of rows processed) you would not > be able to > do this. > > Anthony > > Keating, Tim wrote: > > >This seems like engineering a solution for a non-existent > problem. You > >can > >achieve the same effect by simply making the statement a stored > >procedure, > >which every database programmer worth his salt knows how to do. > > > >Just my $0.02. > > > >TK > > > >>-----Original Message----- > >>From: Jekabs Andrushaitis [mailto:j.andrusaitis@konts.lv] > >>Sent: Friday, December 14, 2001 1:28 AM > >>To: 'Python DB-SIG Mailing List' > >>Subject: [DB-SIG] SQL statement parse for Oracle > >> > >> > >>In the Oracle world SQL statement parsing can take > >>considerable CPU/Block IO > >>for complex statements. Well, I am using pre-historic > Oracle DB module > >>(looks like > >>some OLD DCOracle to me:), however I did not see anything > >>related to this in > >>DBAPI too. > >>What I am talking about is API to allow to parse statement > >>for a cursor (for > >>Oracle > >>OCI it is done by 'oparse' calls) without executing it. It > >>could be used to > >>speed > >>up things in situation where same statement has to be > >>executed several times > >>with different bind variables for example. Or when you want > >>application uses > >>persistand DB connection and you can create several cursors for each > >>operation > >>you need to perform thus eliminating cost of parsing each > >>statement over and > >>over > >>again... > >> > >>From DB-API's point of view it could be Python methods for > >>cursor object: > >> dbc.parse('some statement here') > >> dbc.executeparsed([some bind variables here]) > >> > >>This can be a very useful feature for DBAPI to have, since in > >>case of Oracle > >>and > >>complex statements executed many times it can make the > >>difference visible. > >> > >>I have made made these patches for my OLD OLD Oracle module > >>(sadly I have > >>to stick with it for now cause of other patches weve made in > >>it - Python DB > >>connection > >>object creation from embedded SQL connections, various memory > >>leak fixes > >>which > >>were critical in the environment I am using this module etc:)... > >> > >>Maybe I am totally missing something about DBAPI spec, and if above > >>described > >>features do exist in the spec, then ignore this silly mail :) > >> > >>Also, I am not aware of RDBMS supporting parsing without > >>executing, but > >>Oracle > >>certainly is one of those :) > >> > >>Jekabs > >> > >> > >>_______________________________________________ > >>DB-SIG maillist - DB-SIG@python.org > >>http://mail.python.org/mailman/listinfo/db-sig > >> > > > >_______________________________________________ > >DB-SIG maillist - DB-SIG@python.org > >http://mail.python.org/mailman/listinfo/db-sig > > > > From anthony@computronix.com Fri Dec 14 17:31:24 2001 From: anthony@computronix.com (Anthony Tuininga) Date: Fri, 14 Dec 2001 10:31:24 -0700 Subject: [DB-SIG] SQL statement parse for Oracle References: <3C19CC1A.103B8FFB@lemburg.com> Message-ID: <3C1A376C.3030605@computronix.com> Ok, that sounds reasonable. I have one question, though. Is the last ".command" meant to be ".statement"? In other words, is the statement that is prepared stored with the cursor and then also passed to the execute function? Like this? cursor.prepare("SQL") cursor.execute(cursor.statement, parameters) If that is what is intended, I can live with that as there is a simple pointer comparison in order to determine if the statement ought to be parsed or not. Anthony M.-A. Lemburg wrote: >Jekabs Andrushaitis wrote: > >>In the Oracle world SQL statement parsing can take considerable >> >CPU/Block IO > >>for complex statements. >>... >>What I am talking about is API to allow to parse statement for a >> >cursor (for > >>Oracle >>OCI it is done by 'oparse' calls) without executing it. It could be >> >used to > >>speed >>up things in situation where same statement has to be executed several >> >times > >>with different bind variables for example. >> > >This is already possible using the .execute() command cache which >is described in the DB API. > >>Or when you want application uses >>persistand DB connection and you can create several cursors for each >>operation >>you need to perform thus eliminating cost of parsing each statement >> >over and > >>over >>again... >> > >See above. > >The only problem is that you have to execute the statement at least >once to get it prepared on the cursor. This isn't much of a problem >though if you wrap the DB API cursor objects in more elaborate >Python objects (for abstraction purposes or to extend them with >new features you need). > >The reason for not putting this into the DB API is that some >DBs may not be able to separate the prepare and the execute >steps, e.g. some ODBC drivers only pretend to prepare the >statement -- the actual parsing etc. still takes place at >.execute() time. > >Perhaps I should add a .prepare() method to the set of standard >DB API extensions though ?! > >Here's what I have in mxODBC: > > .prepare(operation) > > Prepare a database operation (query or command) statement for > later execution and set cursor.command. > To execute a prepared statement, pass > cursor.statement to one of the .executeXXX() methods. > Return values are not defined. > >and > > .command > > Provides access to the last prepared or executed SQL command > available through the cursor. If no such command is available, > None is returned. > From anthony@computronix.com Fri Dec 14 18:01:31 2001 From: anthony@computronix.com (Anthony Tuininga) Date: Fri, 14 Dec 2001 11:01:31 -0700 Subject: [DB-SIG] SQL statement parse for Oracle References: <2292DBED5A978A498EABCCE95524499E0281D900@osi-postal.osi.ad.ea.com> Message-ID: <3C1A3E7B.2090303@computronix.com> Ok, that seems rather condescending.... Or it might just be me..... :-) The problem with creating a stored procedure is that you lose complete control. If you wanted to, for example, print something to stdout for each row processed (or set of rows processed) you would not be able to do this. Anthony Keating, Tim wrote: >This seems like engineering a solution for a non-existent problem. You >can >achieve the same effect by simply making the statement a stored >procedure, >which every database programmer worth his salt knows how to do. > >Just my $0.02. > >TK > >>-----Original Message----- >>From: Jekabs Andrushaitis [mailto:j.andrusaitis@konts.lv] >>Sent: Friday, December 14, 2001 1:28 AM >>To: 'Python DB-SIG Mailing List' >>Subject: [DB-SIG] SQL statement parse for Oracle >> >> >>In the Oracle world SQL statement parsing can take >>considerable CPU/Block IO >>for complex statements. Well, I am using pre-historic Oracle DB module >>(looks like >>some OLD DCOracle to me:), however I did not see anything >>related to this in >>DBAPI too. >>What I am talking about is API to allow to parse statement >>for a cursor (for >>Oracle >>OCI it is done by 'oparse' calls) without executing it. It >>could be used to >>speed >>up things in situation where same statement has to be >>executed several times >>with different bind variables for example. Or when you want >>application uses >>persistand DB connection and you can create several cursors for each >>operation >>you need to perform thus eliminating cost of parsing each >>statement over and >>over >>again... >> >>From DB-API's point of view it could be Python methods for >>cursor object: >> dbc.parse('some statement here') >> dbc.executeparsed([some bind variables here]) >> >>This can be a very useful feature for DBAPI to have, since in >>case of Oracle >>and >>complex statements executed many times it can make the >>difference visible. >> >>I have made made these patches for my OLD OLD Oracle module >>(sadly I have >>to stick with it for now cause of other patches weve made in >>it - Python DB >>connection >>object creation from embedded SQL connections, various memory >>leak fixes >>which >>were critical in the environment I am using this module etc:)... >> >>Maybe I am totally missing something about DBAPI spec, and if above >>described >>features do exist in the spec, then ignore this silly mail :) >> >>Also, I am not aware of RDBMS supporting parsing without >>executing, but >>Oracle >>certainly is one of those :) >> >>Jekabs >> >> >>_______________________________________________ >>DB-SIG maillist - DB-SIG@python.org >>http://mail.python.org/mailman/listinfo/db-sig >> > >_______________________________________________ >DB-SIG maillist - DB-SIG@python.org >http://mail.python.org/mailman/listinfo/db-sig > From anthony@computronix.com Fri Dec 14 18:05:46 2001 From: anthony@computronix.com (Anthony Tuininga) Date: Fri, 14 Dec 2001 11:05:46 -0700 Subject: [DB-SIG] SQL statement parse for Oracle References: <3C1A38CF.72CFFA54@lemburg.com> Message-ID: <3C1A3F7A.8060203@computronix.com> Sounds good to me. Note that the DB API document currently specifies "operation". Perhaps this attribute can be called "operation" or we can change the documentation? And does anyone else have any comments? I can implement this in cx_Oracle as well, thus creating a default standard, but I would prefer to have this changed in the API if at all possible. Anthony M.-A. Lemburg wrote: >Anthony Tuininga wrote: > >>Ok, that sounds reasonable. I have one question, though. Is the last >>".command" meant to be ".statement"? >> > >I called it .command because the SQL you execute is not always a >statement. > >>In other words, is the statement >>that is prepared stored with the cursor and then also passed to the >>execute function? Like this? >> >>cursor.prepare("SQL") >>cursor.execute(cursor.statement, parameters) >> > >Yes, that's the idea. This is needed in order to make the whole >thing compatible to the .executexxx() methods. > > >>If that is what is intended, I can live with that as there is a simple >>pointer comparison in order to determine if the statement ought to be >>parsed or not. >> > >Right, that's the idea -- you sort of reuse the .execute() caching >idea for separating the two steps. > > >>M.-A. Lemburg wrote: >> >>>Perhaps I should add a .prepare() method to the set of standard >>>DB API extensions though ?! >>> >>>Here's what I have in mxODBC: >>> >>> .prepare(operation) >>> >>> Prepare a database operation (query or command) statement for >>> later execution and set cursor.command. >>> To execute a prepared statement, pass >>> cursor.statement to one of the .executeXXX() methods. >>> Return values are not defined. >>> >>>and >>> >>> .command >>> >>> Provides access to the last prepared or executed SQL command >>> available through the cursor. If no such command is >>> >available, > >>> None is returned. >>> > From anthony@computronix.com Fri Dec 14 18:35:24 2001 From: anthony@computronix.com (Anthony Tuininga) Date: Fri, 14 Dec 2001 11:35:24 -0700 Subject: [DB-SIG] SQL statement parse for Oracle References: <2292DBED5A978A498EABCCE95524499E0281D905@osi-postal.osi.ad.ea.com> Message-ID: <3C1A466C.8070300@computronix.com> Well, it isn't as much work as you think.... Especially if the solution proposed by Marc is implemented. And the best part of it is that those who don't care, don't __have__ to care. Anthony Keating, Tim wrote: >No condescension intended, it just seems to me that if the client starts >doing SQL parses and caching the results, you're shifting a chunk of >functionality from the server to the client. It's also way more client >than >(IMHO) most people need, and the desired result (minimizing SQL parses) >can >be achieved with an existing piece of functionality. > >I also suspect that this would be a lot harder to do than it sounds like >on >paper. > >TK > >>-----Original Message----- >>From: Anthony Tuininga [mailto:anthony@computronix.com] >>Sent: Friday, December 14, 2001 12:02 PM >>To: Keating, Tim >>Cc: 'j.andrusaitis@konts.lv'; 'Python DB-SIG Mailing List' >>Subject: Re: [DB-SIG] SQL statement parse for Oracle >> >> >>Ok, that seems rather condescending.... Or it might just be >>me..... :-) >> >>The problem with creating a stored procedure is that you lose >>complete >>control. If you wanted to, for example, print something to stdout for >>each row processed (or set of rows processed) you would not >>be able to >>do this. >> >>Anthony >> >>Keating, Tim wrote: >> >>>This seems like engineering a solution for a non-existent >>> >>problem. You >> >>>can >>>achieve the same effect by simply making the statement a stored >>>procedure, >>>which every database programmer worth his salt knows how to do. >>> >>>Just my $0.02. >>> >>>TK >>> >>>>-----Original Message----- >>>>From: Jekabs Andrushaitis [mailto:j.andrusaitis@konts.lv] >>>>Sent: Friday, December 14, 2001 1:28 AM >>>>To: 'Python DB-SIG Mailing List' >>>>Subject: [DB-SIG] SQL statement parse for Oracle >>>> >>>> >>>>In the Oracle world SQL statement parsing can take >>>>considerable CPU/Block IO >>>>for complex statements. Well, I am using pre-historic >>>> >>Oracle DB module >> >>>>(looks like >>>>some OLD DCOracle to me:), however I did not see anything >>>>related to this in >>>>DBAPI too. >>>>What I am talking about is API to allow to parse statement >>>>for a cursor (for >>>>Oracle >>>>OCI it is done by 'oparse' calls) without executing it. It >>>>could be used to >>>>speed >>>>up things in situation where same statement has to be >>>>executed several times >>>>with different bind variables for example. Or when you want >>>>application uses >>>>persistand DB connection and you can create several cursors for each >>>>operation >>>>you need to perform thus eliminating cost of parsing each >>>>statement over and >>>>over >>>>again... >>>> >>>>From DB-API's point of view it could be Python methods for >>> >>>>cursor object: >>>> dbc.parse('some statement here') >>>> dbc.executeparsed([some bind variables here]) >>>> >>>>This can be a very useful feature for DBAPI to have, since in >>>>case of Oracle >>>>and >>>>complex statements executed many times it can make the >>>>difference visible. >>>> >>>>I have made made these patches for my OLD OLD Oracle module >>>>(sadly I have >>>>to stick with it for now cause of other patches weve made in >>>>it - Python DB >>>>connection >>>>object creation from embedded SQL connections, various memory >>>>leak fixes >>>>which >>>>were critical in the environment I am using this module etc:)... >>>> >>>>Maybe I am totally missing something about DBAPI spec, and if above >>>>described >>>>features do exist in the spec, then ignore this silly mail :) >>>> >>>>Also, I am not aware of RDBMS supporting parsing without >>>>executing, but >>>>Oracle >>>>certainly is one of those :) >>>> >>>>Jekabs >>>> >>>> >>>>_______________________________________________ >>>>DB-SIG maillist - DB-SIG@python.org >>>>http://mail.python.org/mailman/listinfo/db-sig >>>> >>>_______________________________________________ >>>DB-SIG maillist - DB-SIG@python.org >>>http://mail.python.org/mailman/listinfo/db-sig >>> >> > >_______________________________________________ >DB-SIG maillist - DB-SIG@python.org >http://mail.python.org/mailman/listinfo/db-sig > From ecosys@pacific.net.hk Sat Dec 15 11:32:42 2001 From: ecosys@pacific.net.hk (Meeling YAU) Date: Sat, 15 Dec 2001 19:32:42 +0800 Subject: [DB-SIG] (no subject) Message-ID: <><><><><>><><><><>><><><><>><>><><><><><><><> Ecosystems Ltd. 2/F Kingsun Compter Building 40 Shek Pai Wan Road Aberdeen, Hong Kong From magnus@thinkware.se Mon Dec 17 04:15:02 2001 From: magnus@thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Mon, 17 Dec 2001 05:15:02 +0100 Subject: [DB-SIG] SQL statement parse for Oracle In-Reply-To: <3C1A3E7B.2090303@computronix.com> References: <2292DBED5A978A498EABCCE95524499E0281D900@osi-postal.osi.ad.ea.com> Message-ID: <5.1.0.14.0.20011215033115.02a77600@mail.irrblosset.se> At 11:01 2001-12-14 -0700, Anthony Tuininga wrote: >The problem with creating a stored procedure is that you lose complete >control. If you wanted to, for example, print something to stdout for each >row processed (or set of rows processed) you would not be able to do this. There are other problems with stored procedures as well. Last time I looked, there was no standard for stored procedure language. Oracle use PL/SQL, Sybase use Transact SQL etc. Maybe this has been solved with SQL99 and been implemented by all major players and upgraded by all major clients while I looked the other way? ;-) No? So, if you need to support several different RDMBS with your app, stored procedures will make life more difficult for you. Even if you only use Oracle today, you might earn millions in a large installation if you don't have a system which is prohibitively expensive to move to DB2 or something else. Stored procedures adds to the cost of a conversion. (One client of mine switched a system with tens of thousands of users from Oracle to DB2 since the licence costs were ten times higher for Oracle...) Last time Oracle tried to sell me a big database, they talked about how you could use PL/SQL in both their client tools and in the server, and how you could write your code once and then move it between server and client to increase performance or whatever was more important at the time. I can surely see why Oracle thinks I should work like that. Talk about lock-in. But if you normally write your code in Python, and not in Oracle 2000 or whatever it's called these days, it IS an extra burden to switch to another language and another environment. I don't think it requires any major intellectual effort, but you get some more things to keep track of. Especially if you have many installations, it's nice if you can keep the administrative and technical support burden to a minimum. Not having to worry about stored procedures can be one ingredient in such a minimalistic strategy. BTW, I recently bought and read (part of) Joe Celko's SQL for smarties. (BTW, have you noticed that Celko bears a striking resemblance to Flash Gordon's enemy Emperor Ming? :) Apart from the fact that the book is written in a really sloppy way, with little mistakes and unclear references etc, I really feel sad when I see the attempts to write "advanced" code in SQL. What would be trivial in Python soon gets very "advanced" or at least ugly in SQL. /Magnus -- Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From jno@glasnet.ru Mon Dec 17 07:09:57 2001 From: jno@glasnet.ru (Eugene V . Dvurechenski) Date: Mon, 17 Dec 2001 10:09:57 +0300 Subject: [DB-SIG] SQL statement parse for Oracle In-Reply-To: <3C1A3E7B.2090303@computronix.com>; from anthony@computronix.com on Fri, Dec 14, 2001 at 11:01:31AM -0700 References: <2292DBED5A978A498EABCCE95524499E0281D900@osi-postal.osi.ad.ea.com> <3C1A3E7B.2090303@computronix.com> Message-ID: <20011217100957.R5690@glas.net> to be honest, this is not true ;-) you still may access your "stdout" from a stored proc. but the way it is used is not obviuos nor handy... -jno On Fri, Dec 14, 2001 at 11:01:31AM -0700, Anthony Tuininga wrote: > Ok, that seems rather condescending.... Or it might just be me..... :-) > > The problem with creating a stored procedure is that you lose complete > control. If you wanted to, for example, print something to stdout for > each row processed (or set of rows processed) you would not be able to > do this. > > Anthony > > Keating, Tim wrote: > > >This seems like engineering a solution for a non-existent problem. You > >can > >achieve the same effect by simply making the statement a stored > >procedure, > >which every database programmer worth his salt knows how to do. > > > >Just my $0.02. > > > >TK > > > >>-----Original Message----- > >>From: Jekabs Andrushaitis [mailto:j.andrusaitis@konts.lv] > >>Sent: Friday, December 14, 2001 1:28 AM > >>To: 'Python DB-SIG Mailing List' > >>Subject: [DB-SIG] SQL statement parse for Oracle > >> > >> > >>In the Oracle world SQL statement parsing can take > >>considerable CPU/Block IO > >>for complex statements. Well, I am using pre-historic Oracle DB module > >>(looks like > >>some OLD DCOracle to me:), however I did not see anything > >>related to this in > >>DBAPI too. > >>What I am talking about is API to allow to parse statement > >>for a cursor (for > >>Oracle > >>OCI it is done by 'oparse' calls) without executing it. It > >>could be used to > >>speed > >>up things in situation where same statement has to be > >>executed several times > >>with different bind variables for example. Or when you want > >>application uses > >>persistand DB connection and you can create several cursors for each > >>operation > >>you need to perform thus eliminating cost of parsing each > >>statement over and > >>over > >>again... > >> > >>From DB-API's point of view it could be Python methods for > >>cursor object: > >> dbc.parse('some statement here') > >> dbc.executeparsed([some bind variables here]) > >> > >>This can be a very useful feature for DBAPI to have, since in > >>case of Oracle > >>and > >>complex statements executed many times it can make the > >>difference visible. > >> > >>I have made made these patches for my OLD OLD Oracle module > >>(sadly I have > >>to stick with it for now cause of other patches weve made in > >>it - Python DB > >>connection > >>object creation from embedded SQL connections, various memory > >>leak fixes > >>which > >>were critical in the environment I am using this module etc:)... > >> > >>Maybe I am totally missing something about DBAPI spec, and if above > >>described > >>features do exist in the spec, then ignore this silly mail :) > >> > >>Also, I am not aware of RDBMS supporting parsing without > >>executing, but > >>Oracle > >>certainly is one of those :) > >> > >>Jekabs > >> > >> > >>_______________________________________________ > >>DB-SIG maillist - DB-SIG@python.org > >>http://mail.python.org/mailman/listinfo/db-sig > >> > > > >_______________________________________________ > >DB-SIG maillist - DB-SIG@python.org > >http://mail.python.org/mailman/listinfo/db-sig > > > > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig -- SY, jno (PRIVATE PERSON) [ http://www.glasnet.ru/~jno ] a TeleRoss techie [ http://www.aviation.ru/ ] If God meant man to fly, He'd have given him more money. From bogus@does.not.exist.com Mon Dec 17 23:27:17 2001 From: bogus@does.not.exist.com (Andrew Kuchling) Date: Mon, 17 Dec 2001 18:27:17 -0500 Subject: [DB-SIG] Taking over the db-sig mailing list Message-ID: I don't actually do anything with SQL databases any more, so running the DB-SIG list has become a time-consuming chore with no benefit. Does anyone want to take over responsibility for the list and SIG? --amk From andy47@halfcooked.com Mon Dec 17 23:50:53 2001 From: andy47@halfcooked.com (Andy Todd) Date: Tue, 18 Dec 2001 10:50:53 +1100 Subject: [DB-SIG] Taking over the db-sig mailing list References: Message-ID: <3C1E84DD.90707@halfcooked.com> Andrew Kuchling wrote: > I don't actually do anything with SQL databases any more, so running > the DB-SIG list has become a time-consuming chore with no benefit. > Does anyone want to take over responsibility for the list and SIG? > > --amk > What does the job entail? I'm sure potential candidates would like to know what they are letting themselves in for. Regards, Andy -- ----------------------------------------------------------------------- From the desk of Andrew J Todd esq. "Another year older, still no wiser." - Me, on my birthday From akuchlin@mems-exchange.org Tue Dec 18 00:10:06 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon, 17 Dec 2001 19:10:06 -0500 Subject: [DB-SIG] Taking over the db-sig mailing list In-Reply-To: <3C1E84DD.90707@halfcooked.com> References: <3C1E84DD.90707@halfcooked.com> Message-ID: <20011218001006.GA14043@ute.mems-exchange.org> On Tue, Dec 18, 2001 at 10:50:53AM +1100, Andy Todd wrote: >What does the job entail? I'm sure potential candidates would like to >know what they are letting themselves in for. Not much: the list just requires deleting the occasional spam and helping the occasional user who has trouble. The SIG owner should really keep the SIG pages and the database topic guide up to date, too. Neither task would occupy much time, I think. --amk From andy47@halfcooked.com Tue Dec 18 00:45:01 2001 From: andy47@halfcooked.com (Andy Todd) Date: Tue, 18 Dec 2001 11:45:01 +1100 Subject: [DB-SIG] Taking over the db-sig mailing list References: <3C1E84DD.90707@halfcooked.com> <20011218001006.GA14043@ute.mems-exchange.org> Message-ID: <3C1E918D.9020905@halfcooked.com> Andrew Kuchling wrote: > On Tue, Dec 18, 2001 at 10:50:53AM +1100, Andy Todd wrote: > >>What does the job entail? I'm sure potential candidates would like to >>know what they are letting themselves in for. >> > > Not much: the list just requires deleting the occasional spam and > helping the occasional user who has trouble. The SIG owner should > really keep the SIG pages and the database topic guide up to date, > too. Neither task would occupy much time, I think. > > --amk > Well in that case - and in the absence of a more capable maintainer - I'd be happy to give it a go. I don't maintain any db modules but I'm an active user of several and do use RDBMS for a living. Regards, Andy -- ----------------------------------------------------------------------- From the desk of Andrew J Todd esq. "Another year older, still no wiser." - Me, on my birthday From fog@initd.org Tue Dec 18 00:50:01 2001 From: fog@initd.org (Federico Di Gregorio) Date: 18 Dec 2001 01:50:01 +0100 Subject: [DB-SIG] Taking over the db-sig mailing list In-Reply-To: <3C1E918D.9020905@halfcooked.com> References: <3C1E84DD.90707@halfcooked.com> <20011218001006.GA14043@ute.mems-exchange.org> <3C1E918D.9020905@halfcooked.com> Message-ID: <1008636602.3218.51.camel@nenya> --=-YD1I+wV1SS+LUgO6gaj6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2001-12-18 at 01:45, Andy Todd wrote: > Andrew Kuchling wrote: >=20 > > On Tue, Dec 18, 2001 at 10:50:53AM +1100, Andy Todd wrote: > >=20 > >>What does the job entail? I'm sure potential candidates would like to=20 > >>know what they are letting themselves in for. > >> > >=20 > > Not much: the list just requires deleting the occasional spam and > > helping the occasional user who has trouble. The SIG owner should > > really keep the SIG pages and the database topic guide up to date, > > too. Neither task would occupy much time, I think. > > Well in that case - and in the absence of a more capable maintainer -=20 > I'd be happy to give it a go. I don't maintain any db modules but I'm > an active user of several and do use RDBMS for a living. same here (module developer, some rdbms). i already maintain some other mailing list so it would be no hassle for me. btw, i don't know if marc-andre has the time, but as the current db-sig editor, i'll surely vote for him :) ciao, federico --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org 99.99999999999999999999% still isn't 100% but sometimes suffice. -- Me --=-YD1I+wV1SS+LUgO6gaj6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjwekrkACgkQvcCgrgZGjevYDwCfd5KjWxHEBDovAfV2fEWmHTPE uDIAoMYNI+hO7UtU6L79UTT5ZmelaAim =XsQg -----END PGP SIGNATURE----- --=-YD1I+wV1SS+LUgO6gaj6-- From andy@dustman.net Tue Dec 18 01:47:46 2001 From: andy@dustman.net (Andy Dustman) Date: 17 Dec 2001 20:47:46 -0500 Subject: [DB-SIG] Taking over the db-sig mailing list In-Reply-To: References: Message-ID: <1008640066.25684.7.camel@chef.comstar.net> On Mon, 2001-12-17 at 18:27, Andrew Kuchling wrote: > I don't actually do anything with SQL databases any more, so running > the DB-SIG list has become a time-consuming chore with no benefit. > Does anyone want to take over responsibility for the list and SIG? There seems to be no shortage of volunteers, and why not, with platitudes like "time-consuming chore with no benefit"? M-AL would be a good choice, though, if he wants it. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From mal@lemburg.com Tue Dec 18 08:53:46 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 18 Dec 2001 09:53:46 +0100 Subject: [DB-SIG] Taking over the db-sig mailing list References: <1008640066.25684.7.camel@chef.comstar.net> Message-ID: <3C1F041A.6A08D018@lemburg.com> Andy Dustman wrote: > > On Mon, 2001-12-17 at 18:27, Andrew Kuchling wrote: > > I don't actually do anything with SQL databases any more, so running > > the DB-SIG list has become a time-consuming chore with no benefit. > > Does anyone want to take over responsibility for the list and SIG? > > There seems to be no shortage of volunteers, and why not, with > platitudes like "time-consuming chore with no benefit"? M-AL would be a > good choice, though, if he wants it. Thanks for all the flowers :-) Unfortunately, I don't have enough time to spend on this and I'm also a bit biased... I'd rather like to see a non-db module author as SIG owner. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From magnus@thinkware.se Tue Dec 18 09:40:44 2001 From: magnus@thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Tue, 18 Dec 2001 10:40:44 +0100 Subject: [DB-SIG] Taking over the db-sig mailing list In-Reply-To: <20011218001006.GA14043@ute.mems-exchange.org> References: <3C1E84DD.90707@halfcooked.com> <3C1E84DD.90707@halfcooked.com> Message-ID: <5.1.0.14.0.20011218103530.00b5df20@mail.irrblosset.se> At 19:10 2001-12-17 -0500, Andrew Kuchling wrote: >Not much: the list just requires deleting the occasional spam and >helping the occasional user who has trouble. The SIG owner should >really keep the SIG pages and the database topic guide up to date, >too. Neither task would occupy much time, I think. If we want to keep things like the list of database modules up-to-date, and feel that it's too much work, a wiki could be something to consider. Just a thought... I agree with Marc-Andre that it's best that someone who is not a module maintainer handles this. --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From daniel.dittmar@sap.com Tue Dec 18 12:35:37 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Tue, 18 Dec 2001 13:35:37 +0100 Subject: [DB-SIG] Taking over the db-sig mailing list Message-ID: > If we want to keep things like the list of database > modules up-to-date, and feel that it's too much work, > a wiki could be something to consider. Just a thought... +1 This would also be a convenient place for links to database related modules (like the various row->dict), code snippets etc. Daniel -- Daniel Dittmar SAP DB, SAP Labs Berlin daniel.dittmar@sap.com http://www.sapdb.org/ From pobrien@orbtech.com Tue Dec 18 13:51:17 2001 From: pobrien@orbtech.com (Patrick K. O'Brien) Date: Tue, 18 Dec 2001 07:51:17 -0600 Subject: [DB-SIG] Taking over the db-sig mailing list In-Reply-To: <3C1E918D.9020905@halfcooked.com> Message-ID: I'll second that nomination. I know Mr. Todd would do a great job. --- Patrick K. O'Brien Orbtech.com - Your Source For Python Development Services Phone: 314-963-3206 > -----Original Message----- > From: db-sig-admin@python.org [mailto:db-sig-admin@python.org]On Behalf > Of Andy Todd > Sent: Monday, December 17, 2001 6:45 PM > To: Andrew Kuchling > Cc: db-sig@python.org > Subject: Re: [DB-SIG] Taking over the db-sig mailing list > > > Andy Todd wrote: > > Well in that case - and in the absence of a more capable maintainer - > I'd be happy to give it a go. I don't maintain any db modules but I'm an > active user of several and do use RDBMS for a living. > > Regards, > Andy > -- > ----------------------------------------------------------------------- > From the desk of Andrew J Todd esq. > "Another year older, still no wiser." - Me, on my birthday From akuchlin@mems-exchange.org Tue Dec 18 16:59:18 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 18 Dec 2001 11:59:18 -0500 Subject: [DB-SIG] Taking over the db-sig mailing list In-Reply-To: <3C1E918D.9020905@halfcooked.com> References: <3C1E84DD.90707@halfcooked.com> <20011218001006.GA14043@ute.mems-exchange.org> <3C1E918D.9020905@halfcooked.com> Message-ID: <20011218165918.GB16678@ute.mems-exchange.org> On Tue, Dec 18, 2001 at 11:45:01AM +1100, Andy Todd wrote: >Well in that case - and in the absence of a more capable maintainer - >I'd be happy to give it a go. I don't maintain any db modules but I'm an Accepted; thanks! --amk From andy@dustman.net Mon Dec 24 01:38:05 2001 From: andy@dustman.net (Andy Dustman) Date: 23 Dec 2001 20:38:05 -0500 Subject: [DB-SIG] ANNOUNCE: MySQLdb-0.9.2a1 Message-ID: <1009157885.2288.8.camel@chef.comstar.net> For those who are interested, there is an alpha release of MySQLdb-0.9.2 on SourceForge: http://sourceforge.net/project/showfiles.php?group_id=22307&release_id=66881 Changes: * Added a number of DB-API extensions. (These are the ones MAL has been working on; no PEP number yet.) * Unicode instances can now be used as parameters to cursor.execute(). It attempts to use whatever character set MySQL is using. If that can't be determined, then latin1 is used. * Mac OS X configuration linkage fix (Dan Grassi) * netbsd configuration (Tage Stabell-Kuloe) http://sourceforge.net/projects/mysql-python/ -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons.