From djc@object-craft.com.au Mon Jul 2 07:33:01 2001 From: djc@object-craft.com.au (Dave Cole) Date: 02 Jul 2001 16:33:01 +1000 Subject: [DB-SIG] MS SQL Server module in development Message-ID: For the last couple of weeks I have been developing a Python module to interface to MS SQL Server. MS SQL Server uses a DB library which looks a lot like the old Sybase DB library. The module work when compiled against either library - meaning you can run the module in any of the following combinations: Client Server ====== ====== Unix Sybase Unix MS SQL Server Windows Sybase Windows MS SQL Server The development is probably a few days away from the point where I will make the first public announcement, but I have hit a bit of a conceptual block. The DB library only allows a single result set to be in flight over a server connection. To make it possible to open multiple cursors simultaneously I have done the "obvious" thing of opening a new connection for each cursor. This introduces the problem: how can I implement Connection.commit() and Connection.rollback()? I really have two options: 1) Do not allow multiple simultaneous cursors on a connection. 2) Implement Cursor.commit() and Cursor.rollback() Can anyone else think of any other options? For the morbidly curious, here is the web page: http://www.object-craft.com.au/projects/mssql/ Here are the current items on my TODO list: * implement Connection.commit(), Connection.close() * improve message/error collection mechanism * change Cursor.callproc() parameter passing to sequence (from dict) * implement some sort of parameter passing to Cursor.execute() * implement BLOB support - Dave -- http://www.object-craft.com.au From andy@dustman.net Mon Jul 2 14:42:53 2001 From: andy@dustman.net (Andy Dustman) Date: Mon, 2 Jul 2001 09:42:53 -0400 (EDT) Subject: [DB-SIG] MS SQL Server module in development In-Reply-To: Message-ID: On 2 Jul 2001, Dave Cole wrote: > MS SQL Server uses a DB library which looks a lot like the old Sybase > DB library. That makes sense, since supposedly MS SQL Server was derived from Sybase. > The DB library only allows a single result set to be in flight over a > server connection. To make it possible to open multiple cursors > simultaneously I have done the "obvious" thing of opening a new > connection for each cursor. > > This introduces the problem: how can I implement Connection.commit() > and Connection.rollback()? > > I really have two options: > > 1) Do not allow multiple simultaneous cursors on a connection. > > 2) Implement Cursor.commit() and Cursor.rollback() > > Can anyone else think of any other options? MySQL has similar implementation details. There are two ways to get the result set (in the C API): * mysql_store_result(): retrieves all rows of the result set from the server and stores them on the client side. * mysql_use_result(): keeps the result set on the server. Rows are returned to the client application via mysql_fetch_row(). If mysql_store_result() was used, the row is already in memory. OTOH, if mysql_use_result() was used, the row has to be retrieved from the server. Note that if mysql_store_result() is used, another query can be issued right away, but this is illegal if mysql_use_result was used: All rows must be retrieved before new queries can be executed. In MySQLdb, the default Cursor class uses mysql_store_result(), but in addition, it immediately fetches all rows, storing them in python-space inside the cursor, and freeing them in the client library (mysql_free_result()). If you have a very large result set, this can be a problem, so there is also a SSCursor that employs mysql_use_result(), and fetches rows one-by-one. You cannot have more than one active SSCursors at the same time, and must fetch all the rows and close the cursor before creating another one. At present, this must be enforced by user discipline. I don't think cursor.commit() is a good option. -- Andy Dustman PGP: 0xC72F3F1D @ .net http://dustman.net/andy I'll give spammers one bite of the apple, but they'll have to guess which bite has the razor blade in it. From zen@shangri-la.dropbear.id.au Mon Jul 2 14:55:21 2001 From: zen@shangri-la.dropbear.id.au (Stuart Bishop) Date: Mon, 2 Jul 2001 23:55:21 +1000 (EST) Subject: [DB-SIG] MS SQL Server module in development In-Reply-To: Message-ID: On 2 Jul 2001, Dave Cole wrote: > The DB library only allows a single result set to be in flight over a > server connection. To make it possible to open multiple cursors > simultaneously I have done the "obvious" thing of opening a new > connection for each cursor. > > This introduces the problem: how can I implement Connection.commit() > and Connection.rollback()? > > I really have two options: > > 1) Do not allow multiple simultaneous cursors on a connection. > > 2) Implement Cursor.commit() and Cursor.rollback() > > Can anyone else think of any other options? Implement Cursor.commit() and Cursor.rollback(). To emulate 'standard' commit/rollback behaviour Connection.commit() and Connection.rollback() then simply to call the corresponding method on all Cursor objects that it has produced (which is easy as your Connection.cursor() method maintains a dictionary of weak references to the Cursor objects it produces). Oh... I see... The real problem will be what to do if one of the commits or rollbacks fails while the Connection object is iterating over its list of cursors... bugger. It might be worth looking at how the PerlDBI, JDBC or ODBC drivers handle the situation. -- Stuart Bishop From djc@object-craft.com.au Tue Jul 3 06:39:04 2001 From: djc@object-craft.com.au (Dave Cole) Date: 03 Jul 2001 15:39:04 +1000 Subject: [DB-SIG] MS SQL Server module in development In-Reply-To: Andy Dustman's message of "Mon, 2 Jul 2001 09:42:53 -0400 (EDT)" References: Message-ID: >>>>> "Andy" == Andy Dustman writes: Andy> MySQL has similar implementation details. There are two ways to Andy> get the result set (in the C API): Andy> * mysql_store_result(): retrieves all rows of the result set Andy> from the server and stores them on the client side. Andy> * mysql_use_result(): keeps the result set on the server. Andy> Rows are returned to the client application via Andy> mysql_fetch_row(). If mysql_store_result() was used, the row is Andy> already in memory. OTOH, if mysql_use_result() was used, the row Andy> has to be retrieved from the server. Note that if Andy> mysql_store_result() is used, another query can be issued right Andy> away, but this is illegal if mysql_use_result was used: All rows Andy> must be retrieved before new queries can be executed. Ahhh... Andy> In MySQLdb, the default Cursor class uses mysql_store_result(), Andy> but in addition, it immediately fetches all rows, storing them Andy> in python-space inside the cursor, and freeing them in the Andy> client library (mysql_free_result()). If you have a very large Andy> result set, this can be a problem, so there is also a SSCursor Andy> that employs mysql_use_result(), and fetches rows Andy> one-by-one. You cannot have more than one active SSCursors at Andy> the same time, and must fetch all the rows and close the cursor Andy> before creating another one. At present, this must be enforced Andy> by user discipline. Andy> I don't think cursor.commit() is a good option. I don't either. That is why I posted to this mailing list. After reading this message I think I have worked out how to solve the problem. By default I will fetch the complete result in the Cursor.execute() then return the result row by row in fetchone(), ... I will also offer an alternate cursor which fetches results on demand. This cursor will set a busy flag in the Connection object. If you attempt to open a new cursor, commit, or rollback while the connection is busy then the method will raise an exception. The only remaining question/issues are: 1) Should I raise an exception, or should I just make the on-demand cursor fallback to a fetchall cursor and clear the busy state. 2) If I implement all cursors as on-demand then I can automatically turn them into fetchall cursors if the cursor(), commit(), or rollback() methods are called on the connection. Any other ideas? - Dave -- http://www.object-craft.com.au From jlg@galaxia.ca Tue Jul 10 18:07:31 2001 From: jlg@galaxia.ca (Lepage, Jonathan) Date: Tue, 10 Jul 2001 13:07:31 -0400 Subject: [DB-SIG] DB2 query and string Message-ID: <7305377E77F6D11181380060945755D1BDAFA7@ActMTL.ACT.QC.CA> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10962.D12F3924 Content-Type: text/plain; charset="iso-8859-1" Hello, I'm using db2.pyd dor windows and IBM DB2 7.1 I have succesfully connected to the db and created my cursor. SQL commands seems to work perfectly. I tried doing a simple select : curs.execute("Select * from patate") and so far no error message. However while doing any fetch i receive SQL_SUCCESFUL_WITH_INFO and no value is returned. If I do my query only on numerals I see my values and receive no error or msg. I've look into the table and everything is there. Is there something i forgot in the setting or is there a parameter i need to pass to fetch to tell it to retreive strings (the error only seems to appear when handling strings). Thanks, Jonathan Lepage Galaxia ------_=_NextPart_001_01C10962.D12F3924 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DB2 query and string

Hello,

       = I'm using db2.pyd dor windows and IBM DB2 7.1  I have succesfully = connected to the db and created my cursor. SQL commands seems to work = perfectly. I tried doing a simple select : curs.execute("Select * = from patate") and so far no error message. However while doing any = fetch i receive SQL_SUCCESFUL_WITH_INFO and no value is returned.  = If I do my query only on numerals I see my values and receive no error = or msg. I've look into the table and everything is there.  Is = there something i forgot in the setting or is there a parameter i need = to pass to fetch to tell it to retreive strings (the error only seems = to appear when handling strings). 

Thanks,

Jonathan Lepage
Galaxia

------_=_NextPart_001_01C10962.D12F3924-- From mal@lemburg.com Tue Jul 10 19:28:24 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 10 Jul 2001 20:28:24 +0200 Subject: [DB-SIG] DB2 query and string References: <7305377E77F6D11181380060945755D1BDAFA7@ActMTL.ACT.QC.CA> Message-ID: <3B4B4948.E88FD313@lemburg.com> > "Lepage, Jonathan" wrote: > > Hello, > > I'm using db2.pyd dor windows and IBM DB2 7.1 I have > succesfully connected to the db and created my cursor. SQL commands > seems to work perfectly. I tried doing a simple select : > curs.execute("Select * from patate") and so far no error message. > However while doing any fetch i receive SQL_SUCCESFUL_WITH_INFO and no > value is returned. This usually means that there was some warning issued at CLI level or that there still is data waiting to be fetched. > If I do my query only on numerals I see my values > and receive no error or msg. I've look into the table and everything > is there. Is there something i forgot in the setting or is there a > parameter i need to pass to fetch to tell it to retreive strings (the > error only seems to appear when handling strings). Alternatively, you can try mxODBC which works just fine with DB2 on Windows using the Windows ODBC manager. You can download mxODBC from the Python Software link below. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From jrodriguez3@cinci.rr.com Thu Jul 12 03:28:07 2001 From: jrodriguez3@cinci.rr.com (Jose Rodriguez) Date: Wed, 11 Jul 2001 22:28:07 -0400 Subject: [DB-SIG] Connecting to MS SQL Server, Access, Oracle examples Message-ID: <000a01c10a7a$49d49140$1ec91d41@mbtrdlptp1> This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C10A58.C2706470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ladies, Gentlemen, I am beginning to learn more about how to use Python to access = external databases. I have got to be perfectly honest in that I learn = best by example. Can anyone assist concerning posting an example or = better explaining how to attach to and manipulate data within a database = especially to MS SQL Server or Access via ODBC connection? I appreciate any and all assistance with this matter. ------=_NextPart_000_0007_01C10A58.C2706470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Ladies, Gentlemen,
 
        I am = beginning to=20 learn more about how to use Python to access external databases.  I = have=20 got to be perfectly honest in that I learn best by example.  Can = anyone=20 assist concerning posting an example or better explaining how to attach = to and=20 manipulate data within a database especially to MS SQL Server or Access = via ODBC=20 connection?
 
        I = appreciate any and=20 all assistance with this matter.
 
 
------=_NextPart_000_0007_01C10A58.C2706470-- From djc@object-craft.com.au Thu Jul 12 03:45:48 2001 From: djc@object-craft.com.au (Dave Cole) Date: 12 Jul 2001 12:45:48 +1000 Subject: [DB-SIG] Connecting to MS SQL Server, Access, Oracle examples In-Reply-To: "Jose Rodriguez"'s message of "Wed, 11 Jul 2001 22:28:07 -0400" References: <000a01c10a7a$49d49140$1ec91d41@mbtrdlptp1> Message-ID: >>>>> "Jose" == Jose Rodriguez writes: Jose> Ladies, Gentlemen, Jose> I am beginning to learn more about how to use Python to Jose> access external databases. I have got to be perfectly honest in Jose> that I learn best by example. Can anyone assist concerning Jose> posting an example or better explaining how to attach to and Jose> manipulate data within a database especially to MS SQL Server or Jose> Access via ODBC connection? Jose> I appreciate any and all assistance with this matter. If you are prepared to try alternatives, you can use my MSSQL Server module. It is still early days but I have not received any reports of it not working. I have not received any reports of it working either - but that is another issue... There is still more work to be done with the module - announcements will be made to this mailing list. Go to this page: http://www.object-craft.com.au/projects/mssql/ Get the module: http://www.object-craft.com.au/projects/mssql/mssql-0.04.tar.gz If you unpack the archive you will find a pre-compiled binary module for Windows. As the page says, you should be able to simply do things like this: >>> import MSSQL >>> db = MSSQL.connect('rat', 'sa', '', 'pubs') >>> c = db.cursor() >>> c.execute('select * from titles') >>> c.fetchone() ('BU1032', "The Busy Executive's Database Guide", 'business ', '1389', 19.99, 5000.00, 10, 4095, 'An overview of available database systems with\015\012emphasis on common business applications. Illustrated.', Jun 12 1991 12:00:00:000AM) >>> for f in c.description: print f ... ('title_id', 47, 0, 7, 0, 0, 0) ('title', 47, 0, 81, 0, 0, 0) ('type', 47, 0, 13, 0, 0, 0) ('pub_id', 47, 0, 5, 0, 0, 0) ('price', 60, 0, 8, 0, 0, 0) ('advance', 60, 0, 8, 0, 0, 0) ('royalty', 56, 0, 4, 0, 0, 0) ('ytd_sales', 56, 0, 4, 0, 0, 0) ('notes', 47, 0, 201, 0, 0, 0) ('pubdate', 61, 0, 8, 0, 0, 0) >>> c = db.cursor() >>> c.callproc('sp_help', {'': 'titles'}) >>> c.fetchall() [] >>> c.nextset() 1 >>> for f in c.fetchall(): print f ... ('titles', 'dbo', 'user table', Nov 13 1998 3:10:48:970AM) >>> c.nextset() 1 >>> for f in c.fetchall(): print f ... ('title_id', 'tid', 'no', 6, ' ', ' ', 'no', 'yes', 'no') ('title', 'varchar', 'no', 80, ' ', ' ', 'no', 'yes', 'no') ('type', 'char', 'no', 12, ' ', ' ', 'no', 'yes', 'no') ('pub_id', 'char', 'no', 4, ' ', ' ', 'yes', 'yes', 'yes') ('price', 'money', 'no', 8, '19 ', '4 ', 'yes', '(n/a)', '(n/a)') ('advance', 'money', 'no', 8, '19 ', '4 ', 'yes', '(n/a)', '(n/a)') ('royalty', 'int', 'no', 4, '10 ', '0 ', 'yes', '(n/a)', '(n/a)') ('ytd_sales', 'int', 'no', 4, '10 ', '0 ', 'yes', '(n/a)', '(n/a)') ('notes', 'varchar', 'no', 200, ' ', ' ', 'yes', 'yes', 'no') ('pubdate', 'datetime', 'no', 8, ' ', ' ', 'no', '(n/a)', '(n/a)') >>> c.nextset() 1 >>> for f in c.fetchall(): print f ... ('No identity column defined.', None, None, None) >>> - Dave -- http://www.object-craft.com.au From mal@lemburg.com Thu Jul 12 09:03:22 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 12 Jul 2001 10:03:22 +0200 Subject: [DB-SIG] Connecting to MS SQL Server, Access, Oracle examples References: <000a01c10a7a$49d49140$1ec91d41@mbtrdlptp1> Message-ID: <3B4D59CA.413E95B3@lemburg.com> > If you are prepared to try alternatives, you can use my MSSQL Server > module. Note that your description will work with just about any Python Database API compliant module or package. > >>> import MSSQL > >>> db = MSSQL.connect('rat', 'sa', '', 'pubs') E.g. for mxODBC just change the above lines to from mx.ODBC import Windows db = Windows.DriverConnect('DSN=datasourcename;UID=userid;PWD=passwd') and the rest should work in pretty much the same way (except for maybe the syntax of calling stored procedures and handling of multiple result sets). > >>> c = db.cursor() > >>> c.execute('select * from titles') > >>> c.fetchone() > ('BU1032', "The Busy Executive's Database Guide", 'business ', '1389', 19.99, 5000.00, 10, 4095, 'An overview of available database systems with\015\012emphasis on common business applications. Illustrated.', Jun 12 1991 12:00:00:000AM) > >>> for f in c.description: print f > ... > ('title_id', 47, 0, 7, 0, 0, 0) > ('title', 47, 0, 81, 0, 0, 0) > ('type', 47, 0, 13, 0, 0, 0) > ('pub_id', 47, 0, 5, 0, 0, 0) > ('price', 60, 0, 8, 0, 0, 0) > ('advance', 60, 0, 8, 0, 0, 0) > ('royalty', 56, 0, 4, 0, 0, 0) > ('ytd_sales', 56, 0, 4, 0, 0, 0) > ('notes', 47, 0, 201, 0, 0, 0) > ('pubdate', 61, 0, 8, 0, 0, 0) There are more examples in the http://www.python.org/topics/database Database Topic Guide. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From djc@object-craft.com.au Thu Jul 12 11:01:30 2001 From: djc@object-craft.com.au (Dave Cole) Date: 12 Jul 2001 20:01:30 +1000 Subject: [DB-SIG] Connecting to MS SQL Server, Access, Oracle examples In-Reply-To: "M.-A. Lemburg"'s message of "Thu, 12 Jul 2001 10:03:22 +0200" References: <000a01c10a7a$49d49140$1ec91d41@mbtrdlptp1> <3B4D59CA.413E95B3@lemburg.com> Message-ID: >>>>> "mal" == M -A Lemburg writes: >> If you are prepared to try alternatives, you can use my MSSQL >> Server module. mal> Note that your description will work with just about any Python mal> Database API compliant module or package. Which was exactly my point :-) The module is an attempt to provide a DB-API compliant wrapper for MS SQL Server. - Dave -- http://www.object-craft.com.au From wwwjessie@21cn.com Thu Jul 12 11:01:48 2001 From: wwwjessie@21cn.com (wwwjessie@21cn.com) Date: Thu, 12 Jul 2001 18:01:48 +0800 Subject: [DB-SIG] =?gb2312?B?xvPStcnPzfijrNK7sr21vc67KFlvdXIgb25saW5lIGNvbXBhbnkp?= Message-ID: <34e4e01c10ab9$aa26c6a0$9300a8c0@ifood1gongxing> This is a multi-part message in MIME format. ------=_NextPart_000_34E4F_01C10AFC.B84A06A0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 1/C+tLXEu+HUsaOsxPq6w6Oh0rzKs8a31tC5+s34t/7O8dDFz6K5qcT6ss6/vKO6ICANCg0K07XT 0NfUvLq1xM34yc+5q8u+o6zVucq+uavLvrL6xre6zbf+zvGjrMzhuN/G89K1vrrV+cGmLMT609DB vdbW0aHU8aO6DQoNCjEvIM341b62qNbGIDxodHRwOi8vd3d3Lmlmb29kMS5jb20vYWJvdXR1cy9v dXJzZXJ2aWNlcy93ZWIuYXNwPiAgOg0K19S8us6su6S4/NDCo6y53MDtx7DMqLrzzKijrLj5vt3G 89K10OjSqqOsvajBotfUvLq1xM34yc+5q8u+o6zK/b7dv+LEo7/pyM7E+tGh1PGjusnMx+nQxc+i t6KyvCzN+MnPsvrGt9W5yr6jrL/Nu6e3/s7x1tDQxCzN+MnPubrO78+1zbMsv827p7nYDQrPtbnc wO0szfjJz8LbzLMszfjJz7vh0unW0NDELM34yc/V0Ma4LM22xrHPtc2zLNfKwc/PwtTY1tDQxCzO yr7ttfey6Swg1dCx6rLJubrPtc2zLLfDzsrV382zvMa31s72LCDBxMzsytIovbvB96GizLjF0Cmh raGtDQoNCs/rwcu94sr9vt2/4sSjv+nR3cq+1tDQxKO/x+vBqs+1o7ogc2FsZXNAaWZvb2QxLmNv bSA8bWFpbHRvOnNhbGVzQGlmb29kMS5jb20+DQqhobXnu7CjujA3NTUtMzc4NjMwOaGhz/rK27K/ yfLQob3jDQoNCjIvINK8zfjNqCA8aHR0cDovL29uZXQuaWZvb2QxLmNvbS8+DQot19TW+sq9vajN +KOsstnX97zytaWjrLy0vai8tNPDo7q/ydW5yr4zMNXFu/K4/Lbg1dXGrKOs19TW+sq9zqy7pKOs v8nL5sqxuPzQws28xqy6zc7E19bE2sjdo6zU2s/ft6KyvLL6xrfQxc+ioaK5q8u+tq/MrLXIo6zU +cvNtv68trn6vMrT8sP7KA0KyOdodHRwOi8veW91cm5hbWUuaWZvb2QxLmNvbSmjrNPr0rzKs8a3 1tC5+s34KNKzw+bkr8DAwb/UwtPiMjAwzfK0zim99MPcway906OszOG438LyvNK6zbnLv823w87K wb+jrLaoxtrK1bW90rzKsw0KxrfW0Ln6zfjM4bmptcS/zbun0OjH87rNssm5utDFz6Khow0KDQoN Cg0KN9TCMzDI1cewyerH67KiuLa/7sq508PSvM34zaijrMzYsfDTxbvdvNszODAw1KovxOqjrNT5 y83M9cLrueO45rKiw+K30dTayrPGt9eo0rXU09a+v6+1x7mpo6zH86OstPrA7aOsus/X99DFz6IN Cs/rwcu94rj8tuA/IKGhx+vBqs+1o7ogc2FsZXNAaWZvb2QxLmNvbSA8bWFpbHRvOnNhbGVzQGlm b29kMS5jb20+DQqhobXnu7CjujA3NTUtMzc4NjMwOaGhoaHP+srbsr/J8tChveMNCrvyILfDzsrO 0sPHtcTN+NKzIDxodHRwOi8vd3d3Lmlmb29kMS5jb20vYWJvdXR1cy9vdXJzZXJ2aWNlcy9jcHNl cnZpY2UuYXNwPg0KOnd3dy5pZm9vZDEuY29tDQoNCrvY1rSjqMfrtKvV5qO6MDc1NS0zMjM5MDQ3 u/K3orXn19PTyrz+o7ogc2FsZXNAaWZvb2QxLmNvbSA8bWFpbHRvOnNhbGVzQGlmb29kMS5jb20+ IKOpDQoNCqH1ILG+uavLvrbUzfjVvrao1sa40NDLyKShoaGhICAgICAgICAgICAgICAgICAgICAg ofUgsb65q8u+ttTSvM34zai3/s7xuNDQy8ikDQoNCrmry77D+7PGo7pfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX1/Bqs+1yMujul9fX19fX19fX19fX19fX19fXw0K X19fX18gDQoNCrXnu7Cjul9fX19fX19fX19fX19fX19fX19fX7Sr1eajul9fX19fX19fX19fX19f X19fX19fX19FLW1haWyjul9fX19fX19fX19fX19fX18NCl9fX19fXyANCg0K ------=_NextPart_000_34E4F_01C10AFC.B84A06A0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5VbnRpdGxlZCBEb2N1bWVudDwvVElUTEU+IDxNRVRBIEhU VFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMx MiI+IA0KPC9IRUFEPg0KDQo8Qk9EWSBCR0NPTE9SPSIjRkZGRkZGIiBURVhUPSIjMDAwMDAwIj4N CjxUQUJMRSBXSURUSD0iOTglIiBCT1JERVI9IjAiIENFTExTUEFDSU5HPSIwIiBDRUxMUEFERElO Rz0iMCI+PFRSPjxURD48UCBDTEFTUz1Nc29Ob3JtYWwgU1RZTEU9J21hcmdpbi1yaWdodDotMTcu ODVwdDtsaW5lLWhlaWdodDoxNTAlJz48Rk9OVCBTSVpFPSIyIj7X8L60tcS74dSxo6zE+rrDo6HS vMqzxrfW0Ln6zfi3/s7x0MXPormpxPqyzr+8o7ombmJzcDs8L0ZPTlQ+IA0KPC9QPjxQIENMQVNT PU1zb05vcm1hbCBTVFlMRT0nbWFyZ2luLXJpZ2h0Oi0xNy44NXB0O2xpbmUtaGVpZ2h0OjE1MCUn PjxGT05UIFNJWkU9IjIiPtO109DX1Ly6tcTN+MnPuavLvqOs1bnKvrmry76y+sa3us23/s7xo6zM 4bjfxvPStb661fnBpizE+tPQwb3W1tGh1PGjujxCUj48QlI+MS8gDQo8QQ0KSFJFRj0iaHR0cDov L3d3dy5pZm9vZDEuY29tL2Fib3V0dXMvb3Vyc2VydmljZXMvd2ViLmFzcCI+zfjVvrao1sY8L0E+ IDog19S8us6su6S4/NDCo6y53MDtx7DMqLrzzKijrLj5vt3G89K10OjSqqOsvajBotfUvLq1xM34 yc+5q8u+o6zK/b7dv+LEo7/pyM7E+tGh1PGjusnMx+nQxc+it6KyvCzN+MnPsvrGt9W5yr6jrL/N u6e3/s7x1tDQxCzN+MnPubrO78+1zbMsv827p7nYz7W53MDtLM34yc/C28yzLM34yc+74dLp1tDQ xCzN+MnP1dDGuCzNtsaxz7XNsyzXysHPz8LU2NbQ0MQszsq+7bX3suksIA0K1dCx6rLJubrPtc2z LLfDzsrV382zvMa31s72LCDBxMzsytIovbvB96GizLjF0CmhraGtPC9GT05UPjwvUD48UCBDTEFT Uz1Nc29Ob3JtYWwgU1RZTEU9J2xpbmUtaGVpZ2h0OjIwLjBwdCc+PEI+PEZPTlQgQ09MT1I9IiNG RjAwMDAiPs/rwcu94sr9vt2/4sSjv+nR3cq+1tDQxKO/PC9GT05UPjwvQj48Rk9OVCBTSVpFPSIy Ij7H68Gqz7WjujxBIEhSRUY9Im1haWx0bzpzYWxlc0BpZm9vZDEuY29tIj5zYWxlc0BpZm9vZDEu Y29tPC9BPiANCqGhtee7sKO6MDc1NS0zNzg2MzA5oaHP+srbsr/J8tChveM8L0ZPTlQ+PC9QPjxQ IENMQVNTPU1zb05vcm1hbCBTVFlMRT0nbGluZS1oZWlnaHQ6MjAuMHB0Jz48L1A+PFAgQ0xBU1M9 TXNvTm9ybWFsIFNUWUxFPSdsaW5lLWhlaWdodDoyMC4wcHQnPjxGT05UIFNJWkU9IjIiPjIvIA0K PEEgSFJFRj0iaHR0cDovL29uZXQuaWZvb2QxLmNvbS8iPtK8zfjNqDwvQT4t19TW+sq9vajN+KOs stnX97zytaWjrLy0vai8tNPDo7q/ydW5yr4zMNXFu/K4/Lbg1dXGrKOs19TW+sq9zqy7pKOsv8nL 5sqxuPzQws28xqy6zc7E19bE2sjdo6zU2s/ft6KyvLL6xrfQxc+ioaK5q8u+tq/MrLXIo6zU+cvN tv68trn6vMrT8sP7KMjnaHR0cDovL3lvdXJuYW1lLmlmb29kMS5jb20po6zT69K8yrPGt9bQufrN +CjSs8Pm5K/AwMG/1MLT4jIwMM3ytM4pvfTD3MGsvdOjrMzhuN/C8rzSus25y7/Nt8POysG/o6y2 qMbaytW1vdK8yrPGt9bQufrN+Mzhuam1xL/Nu6fQ6Mfzus2yybm60MXPoqGjPEJSPjwvRk9OVD48 L1A+PFAgQ0xBU1M9TXNvTm9ybWFsIFNUWUxFPSdtYXJnaW4tcmlnaHQ6LTE3Ljg1cHQ7bGluZS1o ZWlnaHQ6MTUwJSc+PEZPTlQgU0laRT0iMiI+PEJSPjwvRk9OVD4gDQo8Qj48Rk9OVCBDT0xPUj0i I0ZGMDAwMCI+NzwvRk9OVD48L0I+PEZPTlQgQ09MT1I9IiNGRjAwMDAiPjxCPtTCMzDI1cewyerH 67KiuLa/7sq508PSvM34zaijrMzYsfDTxbvdvNszODAw1KovxOqjrNT5y83M9cLrueO45rKiw+K3 0dTayrPGt9eo0rXU09a+v6+1x7mpo6zH86OstPrA7aOsus/X99DFz6I8L0I+PEJSPjwvRk9OVD4g DQo8Rk9OVCBTSVpFPSIyIj7P68HLveK4/LbgPyChocfrwarPtaO6PEEgSFJFRj0ibWFpbHRvOnNh bGVzQGlmb29kMS5jb20iPnNhbGVzQGlmb29kMS5jb208L0E+IA0KoaG157uwo7owNzU1LTM3ODYz MDmhoaGhz/rK27K/yfLQob3jPEJSPjwvRk9OVD48Rk9OVCBTSVpFPSIyIj678jxBDQpIUkVGPSJo dHRwOi8vd3d3Lmlmb29kMS5jb20vYWJvdXR1cy9vdXJzZXJ2aWNlcy9jcHNlcnZpY2UuYXNwIj63 w87KztLDx7XEzfjSszwvQT46d3d3Lmlmb29kMS5jb208L0ZPTlQ+PC9QPjxQIENMQVNTPU1zb05v cm1hbCBTVFlMRT0nbGluZS1oZWlnaHQ6MjAuMHB0JyBBTElHTj0iTEVGVCI+PC9QPjxQIENMQVNT PU1zb05vcm1hbCBBTElHTj1MRUZUIFNUWUxFPSdsaW5lLWhlaWdodDoyMC4wcHQnPjxGT05UIFNJ WkU9IjIiPjxCPrvY1rSjqMfrtKvV5qO6MDc1NS0zMjM5MDQ3u/K3orXn19PTyrz+o7o8L0I+PEEN CkhSRUY9Im1haWx0bzpzYWxlc0BpZm9vZDEuY29tIj5zYWxlc0BpZm9vZDEuY29tIDwvQT48Qj6j qTwvQj48L0ZPTlQ+PC9QPjxQPjxGT05UIFNJWkU9IjIiPqH1IA0Ksb65q8u+ttTN+NW+tqjWxrjQ 0MvIpKGhoaEmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IKH1ILG+uavLvrbU0rzN+M2ot/7O8bjQ0MvIpDwvRk9OVD48L1A+PFAgQ0xBU1M9TXNv Tm9ybWFsIFNUWUxFPSdsaW5lLWhlaWdodDoyMC4wcHQnPjxGT05UIFNJWkU9IjIiPrmry77D+7PG o7pfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1/Bqs+1yMujul9f X19fX19fX19fX19fX19fX19fX19fIA0KPEJSPiA8QlI+ILXnu7Cjul9fX19fX19fX19fX19fX19f X19fX7Sr1eajul9fX19fX19fX19fX19fX19fX19fX19FLW1haWyjul9fX19fX19fX19fX19fX19f X19fX18gDQo8L0ZPTlQ+PC9QPjxQIENMQVNTPU1zb05vcm1hbCBTVFlMRT0nbGluZS1oZWlnaHQ6 MjAuMHB0Jz48L1A+PC9URD48L1RSPjwvVEFCTEU+IA0KPC9CT0RZPg0KPC9IVE1MPg0K ------=_NextPart_000_34E4F_01C10AFC.B84A06A0-- From Billy G. Allie" --==_Exmh_-304170496P Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Announce: Third public release of pyPgSQL - Version 1.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= pyPgSQL v1.3 has been released. This is the third public release of pyPgSQL. It is primarily a bug fix release with some minor performance enhancements to the DB-API 2.0 compliant module (see the attached ChangeL= og file for details). It is available at http://sourceforge.net/projects/pypgsql. pyPgSQL is a package of two (2) modules that provide a Python DB-API 2.0 compliant interface to PostgreSQL databases. The first module, libpq, exports the PostgreSQL C API to Python. This module is written in C and can be compiled into Python or can be dynamically loaded on demand. The second module, PgSQL, provides the DB-API 2.0 compliant interface and support for various PostgreSQL data types, such as INT8, NUMERIC, MONEY, BOOL, ARRAYS, etc. This module is written in Python and works with PostgreSQL 6.5.2 or later and Python 1.5.2 or later. PostgreSQL is a sophisticated Object-Relational DBMS, supporting almost a= ll SQL constructs, including sub-selects, transactions, and user-defined typ= es and functions. It is the most advanced open-source database available anywhere More information about PostgreSQL can be found at the PostgreSQL= home page at http://www.postgresql.org. Python is an interpreted, interactive, object-oriented programming lang- uage. It combines remarkable power with very clear syntax. It has modules, classes, exceptions, very high level dynamic data types, and dynamic typing. There are interfaces to many system calls and libraries,= as well as to various windowing systems (X11, Motif, Tk, Mac, MFC). New builtin modules are easily written in C or C++. Python is also usable as= an extension language for applications that need a programmable interface= =2E = Python is copyrighted but freely usable and distributable, even for commercial use. More information about Python can be found on the Python= home page at http://www.python.org. -------------------------------------------------------------------------= -- ChangeLog: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Changes since pyPgSQL Version 1.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D The PgInt2 and PgInt8 type objects (formally implemented as Python classe= s) were re-implemented in C. The PgInt8 C implementation will only be used = if long_longs are supported in your architecture, other wise a Python implem= en- tation will be used (based on Python's long type). Changes to PgSQL.py ------------------- * Used weak references (if available) to remove the problem of circular references between the Connection object and the Cursor objects create= d with it. The circular references between the Connection object and it= 's associated TypeCache object are also resolved. * Fixed incorrect reference to .__reset() in the connection object. * Changed .execute() so that if a SELECT statement is executed the remai= ning results (if any) of a previous SELECT statement is discarded and repla= ced with the results of the new SELECT query. The previous behavior was t= o raise an InterfaceError in that situation. * Since .execute() will call the reset method as needed, the .reset() me= thod was renamed to .__reset() to make private (at least a private as it ge= ts in Python :-). * Change 'version' so that it holds the version number of PgSQL.py. PostgreSQL version information is now held in 'version' attribute of t= he connection object. * Modified the code so that the .close() method in Cursor conforms to th= e DB-API 2.0 specification. Closing a cursor now prevents it from being= used any further, and dis-associates the cursor from it's connection. Committing or rolling back a transaction will no longer closes all the= of connection's cursors. It will, however, reset the cursor to it's init= ial result and invalidate any unread query results. * Reworked the code so that the .__getattr__() method in Cursor is no lo= nger needed. * Change ._reset_() so that it closes the PostgreSQL portal, if one is opened. * Renamed _reset_() to reset() and document it as an extension to the DB-API 2.0 specification. * Updated the PgSQL.__doc__ string. * Added code to load DateTime from an alternate location (from mx import= DateTime) if import DateTime failed. The alternate location came from= a patch submitted by Gerhard H=E4ring . * Minor bug fixes and improvements. * Improved the speed of initializing a new PgResultSet by pre-building t= he name to index dictionary when the cursor description attribute is buil= t. * Modified code to use the C implementation of the PgInt2 object. Changes to libpqmodule.c ------------------------ * To the extent possible, I pick out the "lint" from the code. In the process, I discovered some nasty little bugs in little used (or tested= ) routines. * Changed PyObject_HEAD_INIT(&PyType_Type) to PyObject_HEAD_INIT(NULL) t= o silence error produced by some compilers. * Modified code to use C implementation of PgInt2 type. * Modified code to use C implementation of PgInt8 type. This code will = only be used if LONG_LONG is defined. -- = ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 | --==_Exmh_-304170496P Content-Type: application/pgp-signature -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Announce: Third public release of pyPgSQL - Version 1.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= pyPgSQL v1.3 has been released. This is the third public release of pyPgSQL. It is primarily a bug fix release with some minor performance enhancements to the DB-API 2.0 compliant module (see the attached ChangeL= og file for details). It is available at http://sourceforge.net/projects/pypgsql. pyPgSQL is a package of two (2) modules that provide a Python DB-API 2.0 compliant interface to PostgreSQL databases. The first module, libpq, exports the PostgreSQL C API to Python. This module is written in C and can be compiled into Python or can be dynamically loaded on demand. The second module, PgSQL, provides the DB-API 2.0 compliant interface and support for various PostgreSQL data types, such as INT8, NUMERIC, MONEY, BOOL, ARRAYS, etc. This module is written in Python and works with PostgreSQL 6.5.2 or later and Python 1.5.2 or later. PostgreSQL is a sophisticated Object-Relational DBMS, supporting almost a= ll SQL constructs, including sub-selects, transactions, and user-defined typ= es and functions. It is the most advanced open-source database available anywhere More information about PostgreSQL can be found at the PostgreSQL= home page at http://www.postgresql.org. Python is an interpreted, interactive, object-oriented programming lang- uage. It combines remarkable power with very clear syntax. It has modules, classes, exceptions, very high level dynamic data types, and dynamic typing. There are interfaces to many system calls and libraries,= as well as to various windowing systems (X11, Motif, Tk, Mac, MFC). New builtin modules are easily written in C or C++. Python is also usable as= an extension language for applications that need a programmable interface= =2E = Python is copyrighted but freely usable and distributable, even for commercial use. More information about Python can be found on the Python= home page at http://www.python.org. - -------------------------------------------------------------------------= - -- ChangeLog: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Changes since pyPgSQL Version 1.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D The PgInt2 and PgInt8 type objects (formally implemented as Python classe= s) were re-implemented in C. The PgInt8 C implementation will only be used = if long_longs are supported in your architecture, other wise a Python implem= en- tation will be used (based on Python's long type). Changes to PgSQL.py - ------------------- * Used weak references (if available) to remove the problem of circular references between the Connection object and the Cursor objects create= d with it. The circular references between the Connection object and it= 's associated TypeCache object are also resolved. * Fixed incorrect reference to .__reset() in the connection object. * Changed .execute() so that if a SELECT statement is executed the remai= ning results (if any) of a previous SELECT statement is discarded and repla= ced with the results of the new SELECT query. The previous behavior was t= o raise an InterfaceError in that situation. * Since .execute() will call the reset method as needed, the .reset() me= thod was renamed to .__reset() to make private (at least a private as it ge= ts in Python :-). * Change 'version' so that it holds the version number of PgSQL.py. PostgreSQL version information is now held in 'version' attribute of t= he connection object. * Modified the code so that the .close() method in Cursor conforms to th= e DB-API 2.0 specification. Closing a cursor now prevents it from being= used any further, and dis-associates the cursor from it's connection. Committing or rolling back a transaction will no longer closes all the= of connection's cursors. It will, however, reset the cursor to it's init= ial result and invalidate any unread query results. * Reworked the code so that the .__getattr__() method in Cursor is no lo= nger needed. * Change ._reset_() so that it closes the PostgreSQL portal, if one is opened. * Renamed _reset_() to reset() and document it as an extension to the DB-API 2.0 specification. * Updated the PgSQL.__doc__ string. * Added code to load DateTime from an alternate location (from mx import= DateTime) if import DateTime failed. The alternate location came from= a patch submitted by Gerhard H=E4ring . * Minor bug fixes and improvements. * Improved the speed of initializing a new PgResultSet by pre-building t= he name to index dictionary when the cursor description attribute is buil= t. * Modified code to use the C implementation of the PgInt2 object. Changes to libpqmodule.c - ------------------------ * To the extent possible, I pick out the "lint" from the code. In the process, I discovered some nasty little bugs in little used (or tested= ) routines. * Changed PyObject_HEAD_INIT(&PyType_Type) to PyObject_HEAD_INIT(NULL) t= o silence error produced by some compilers. * Modified code to use C implementation of PgInt2 type. * Modified code to use C implementation of PgInt8 type. This code will = only be used if LONG_LONG is defined. - -- = ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.2 (UnixWare) Comment: Exmh version 2.2 06/23/2000 iD8DBQE7UpgEnmIkMXoVVdURAu8jAJ9lDJw2sCd5Vw0pFDRKXnBh+az8gACaAiCo 6KpgcyUvG+lf+JsvxjJRBEA= =P9XX -----END PGP SIGNATURE----- --==_Exmh_-304170496P-- From wwwjessie@21cn.com Mon Jul 16 10:47:30 2001 From: wwwjessie@21cn.com (wwwjessie@21cn.com) Date: Mon, 16 Jul 2001 17:47:30 +0800 Subject: [DB-SIG] =?gb2312?B?tPPBrC0yMDAxxOq5+rzKwszJq8qzxrfT68jLwOC9ob+1sqnAwLvhKA==?= =?gb2312?B?QWdybyBBbm51YWwgTWVldGluZyBDaGluYSAyMDAxKQ0=?= Message-ID: <2d8ba01c10ddc$5476e9d0$9300a8c0@ifood1gongxing> This is a multi-part message in MIME format. ------=_NextPart_000_2D8BB_01C10E1F.629A29D0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MjAwMcTq1tC5+rn6vMrFqdK1v8a8vMTqu+ENCrn6vMrCzMmryrPGt9PryMvA4L2hv7WyqcDAu+G8 sNGnyvXM1sLbu+ENCg0KCQ0K1bnG2qO6IAmhoTIwMDHE6jnUwjTI1S03yNUJDQq12LXjo7ogCaGh tPPBrNDHuqO74dW51tDQxAkNCtb3sOyjuiAJoaHW0LuqyMvD8bmyus25+sWp0rWyvw0KoaHW0Ln6 v8bRp7y8yvXQrbvhDQqhobTzwazK0MjLw/HV/riuDQoJDQqz0LDso7ogCaGh1tC5+sLMyavKs8a3 t6LVudbQ0MQNCqGh1tC5+sWp0ae74Q0KoaHW0Ln6wszJq8qzxrfQrbvhDQqhobTzwazK0MWp0rW+ 1g0KoaG088Gs0Me6o7vh1bnW0NDEDQoJDQrN+MLnt/7O8czhuanJzKO60rzKs8a31tC5+s34IGh0 dHA6Ly93d3cuaWZvb2QxLmNvbQ0KPGh0dHA6Ly93d3cuaWZvb2QxLmNvbS9pbmRleC5hc3A/ZnI9 ZGItc2lnQHB5dGhvbi5vcmc+IAkNCiAJDQqh+iDNqLn90rzKs8a31tC5+s34sajD+7LO1bmjur7F 1dvTxbvdKLHIyOfP1tPQw7+49iAzTSBYIDNNILXEserXvNW5zrvUrbzbUk1CNDUwMKOszai5/c7S w8fWu9DouLZSTUI0MDUwKaOsDQqxqMP7vdjWucjVxtoyMDAxxOo31MIyMMjVIDxodHRwOi8vZ3Jl ZW4yMDAxLmlmb29kMS5jb20vZnJvbTEuYXNwPiANCqH6ILu2060gw+K30deisuEgPGh0dHA6Ly93 d3cuaWZvb2QxLmNvbS9zaWdudXAvc2V2YWdyZWVtLmFzcD4gs8nOqrmry7674dSxoaMNCjfUwjIw yNXHsNeisuGjrMT6vavU2jfUwjI1yNXHsM2ouf2159fT08q8/re9yr3D4rfRu/G1wzMwzPWyybm6 0MXPoqGjDQrI57n7xPqyu8/rytW1vc7Sw8e1xNPKvP6jrMfrIMGqz7XO0sPHIDxtYWlsdG86dW5z dWJzY3JpYmVAaWZvb2QxLmNvbT4go6zO0sPH0tS6872rsrvU2bei08q8/rj4xPqhow0KsunRr6O6 IHNhbGVzQGlmb29kMS5jb20gPG1haWx0bzpzYWxlc0BpZm9vZDEuY29tPiAgoaGhobXnu7CjujA3 NTUtMzc4NjMwOaGhz/rK27K/DQrJ8tChveMgtsXPyMn6DQoNCg0KIA0KDQq72CDWtCCjqMfrtKvV 5qO6MDc1NS0zMjM5MDQ3u/Igt6K159fT08q8/qO6IHNhbGVzQGlmb29kMS5jb20gPG1haWx0bzpz YWxlc0BpZm9vZDEuY29tPg0Ko6kJDQqh9SCxvrmry77T0NLizai5/dK8yrPGt9bQufrN+LLO1bkg oaGhoSCh9SCxvrmry77E4r340ruyvcHLveK4w7KpwMC74aOsx+vT687Sw8fBqs+1DQoNCrmry77D +7PGo7pfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KwarPtcjLo7pfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq157uwo7pfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQq0q9Xmo7pfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpFLW1haWyjul9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CgkNCiAJDQogCQ0KIAkNCiAJDQogCQ0K ------=_NextPart_000_2D8BB_01C10E1F.629A29D0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+IDxtZXRhIGh0 dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMx MiI+IA0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwhLS0NCnRkIHsgIGxpbmUtaGVpZ2h0OiAy NHB4fQ0KLS0+DQo8L3N0eWxlPiANCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIg dGV4dD0iIzAwMDAwMCI+DQo8ZGl2IGFsaWduPSJDRU5URVIiPjx0YWJsZSB3aWR0aD0iNzUlIiBi b3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+PHRyPjx0ZCBhbGlnbj0i Q0VOVEVSIj48YSBocmVmPSJodHRwOy8vZ3JlZW4yMDAxLmlmb29kMS5jb20iPjxiPjIwMDHE6tbQ ufq5+rzKxanStb/GvLzE6rvhPGJyPrn6vMrCzMmryrPGt9PryMvA4L2hv7WyqcDAu+G8sNGnyvXM 1sLbu+E8L2I+PC9hPjxicj48YnI+PC90ZD48L3RyPjx0cj48dGQgYWxpZ249IkNFTlRFUiI+PHRh YmxlIHdpZHRoPSI3NSUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIw Ij48dHI+PHRkIGhlaWdodD0iMTIiIHdpZHRoPSIzOSUiIGFsaWduPSJSSUdIVCI+PGI+PGZvbnQg c2l6ZT0iMiI+1bnG2qO6IA0KPC9mb250PjwvYj48L3RkPjx0ZCBoZWlnaHQ9IjEyIiB3aWR0aD0i NjElIj48Zm9udCBzaXplPSIyIj6hoTIwMDHE6jnUwjTI1S03yNU8L2ZvbnQ+PC90ZD48L3RyPjx0 cj48dGQgaGVpZ2h0PSIxMiIgd2lkdGg9IjM5JSIgYWxpZ249IlJJR0hUIj48Yj48Zm9udCBzaXpl PSIyIj612LXjo7ogDQo8L2ZvbnQ+PC9iPjwvdGQ+PHRkIGhlaWdodD0iMTIiIHdpZHRoPSI2MSUi Pjxmb250IHNpemU9IjIiPqGhtPPBrNDHuqO74dW51tDQxDwvZm9udD48L3RkPjwvdHI+PHRyPjx0 ZCBoZWlnaHQ9IjEyIiB3aWR0aD0iMzklIiBhbGlnbj0iUklHSFQiIHZhbGlnbj0iVE9QIj48Yj48 Zm9udCBzaXplPSIyIj7W97Dso7ogDQo8L2ZvbnQ+PC9iPjwvdGQ+PHRkIGhlaWdodD0iMTIiIHdp ZHRoPSI2MSUiPjxmb250IHNpemU9IjIiPqGhPC9mb250Pjxmb250IHNpemU9IjIiPtbQu6rIy8Px ubK6zbn6xanStbK/PGJyPqGh1tC5+r/G0ae8vMr10K274Txicj6hobTzwazK0MjLw/HV/riuPGJy PjwvZm9udD48L3RkPjwvdHI+PHRyPjx0ZCBoZWlnaHQ9IjEyIiB3aWR0aD0iMzklIiBhbGlnbj0i UklHSFQiIHZhbGlnbj0iVE9QIj48Yj48Zm9udCBzaXplPSIyIj6z0LDso7ogDQo8L2ZvbnQ+PC9i PjwvdGQ+PHRkIGhlaWdodD0iMTIiIHdpZHRoPSI2MSUiPjxmb250IHNpemU9IjIiPqGhPC9mb250 Pjxmb250IHNpemU9IjIiPtbQufrCzMmryrPGt7ei1bnW0NDEPGJyPqGh1tC5+sWp0ae74Txicj6h odbQufrCzMmryrPGt9Ctu+E8YnI+oaG088GsytDFqdK1vtY8YnI+oaG088Gs0Me6o7vh1bnW0NDE PGJyPjwvZm9udD48L3RkPjwvdHI+PHRyPjx0ZCBjb2xzcGFuPSIyIiBhbGlnbj0iQ0VOVEVSIj48 Zm9udCBzaXplPSIyIj7N+MLnt/7O8czhuanJzKO60rzKs8a31tC5+s34IA0KPGEgaHJlZj0iaHR0 cDovL3d3dy5pZm9vZDEuY29tL2luZGV4LmFzcD9mcj1kYi1zaWdAcHl0aG9uLm9yZyI+aHR0cDov L3d3dy5pZm9vZDEuY29tPC9hPjwvZm9udD48L3RkPjwvdHI+PHRyPjx0ZCBjb2xzcGFuPSIyIiBh bGlnbj0iQ0VOVEVSIj4mbmJzcDs8L3RkPjwvdHI+PHRyPjx0ZCBjb2xzcGFuPSIyIiBhbGlnbj0i TEVGVCI+PHA+PGZvbnQgc2l6ZT0iMiI+ofogDQrNqLn90rzKs8a31tC5+s34sajD+7LO1bmjujxi Pjxmb250IHNpemU9IjMiIGNvbG9yPSIjRkYwMDAwIj6+xdXb08W73TwvZm9udD48L2I+KLHIyOfP 1tPQw7+49iAzTSBYIDNNIA0KtcSx6te81bnOu9StvNtSTUI0NTAwo6zNqLn9ztLDx9a70Oi4tlJN QjQwNTApo6wgPGEgaHJlZj0iaHR0cDovL2dyZWVuMjAwMS5pZm9vZDEuY29tL2Zyb20xLmFzcCI+ PGI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiNGRjAwMDAiPrGow/u92Na5yNXG2jIwMDHE6jfUwjIw yNU8L2ZvbnQ+PC9iPjwvYT48YnI+ofogDQq7ttOtPGEgaHJlZj0iaHR0cDovL3d3dy5pZm9vZDEu Y29tL3NpZ251cC9zZXZhZ3JlZW0uYXNwIj7D4rfR16Ky4TwvYT6zyc6quavLvrvh1LGhoyA8Zm9u dCBjb2xvcj0iI0ZGMDAwMCI+PGI+PGZvbnQgc2l6ZT0iMyI+N9TCMjDI1cew16Ky4aOsxPq9q9Ta N9TCMjXI1cewzai5/bXn19PTyrz+t73KvcPit9G78bXDMzDM9bLJubrQxc+ioaM8L2ZvbnQ+PC9i PjwvZm9udD48YnI+yOe5+8T6srvP68rVtb3O0sPHtcTTyrz+o6zH6zxhIGhyZWY9Im1haWx0bzp1 bnN1YnNjcmliZUBpZm9vZDEuY29tIj7Bqs+1ztLDxzwvYT6jrM7Sw8fS1Lrzvauyu9TZt6LTyrz+ uPjE+qGjPGJyPrLp0a+jujxhIGhyZWY9Im1haWx0bzpzYWxlc0BpZm9vZDEuY29tIj5zYWxlc0Bp Zm9vZDEuY29tPC9hPiANCqGhoaG157uwo7owNzU1LTM3ODYzMDmhoc/6ytuyvyDJ8tChveMgtsXP yMn6PGJyPjwvZm9udD48L3A+PHA+Jm5ic3A7PC9wPjwvdGQ+PC90cj48dHI+PHRkIGhlaWdodD0i MzAiIGNvbHNwYW49IjIiIGFsaWduPSJDRU5URVIiPjxmb250IHNpemU9IjIiPjxiPrvYIA0K1rQg o6jH67Sr1eajujA3NTUtMzIzOTA0N7vyILeitefX09PKvP6juiA8YSBocmVmPSJtYWlsdG86c2Fs ZXNAaWZvb2QxLmNvbSI+c2FsZXNAaWZvb2QxLmNvbTwvYT4gDQqjqTwvYj48L2ZvbnQ+PC90ZD48 L3RyPjx0cj48dGQgaGVpZ2h0PSIxMiIgY29sc3Bhbj0iMiI+PGZvbnQgc2l6ZT0iMiI+ofUgsb65 q8u+09DS4s2ouf3SvMqzxrfW0Ln6zfiyztW5IA0KoaGhoSCh9SCxvrmry77E4r340ruyvcHLveK4 w7KpwMC74aOsx+vT687Sw8fBqs+1PGJyPjxicj65q8u+w/uzxqO6X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+warPtcjLo7pfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPjwvZm9udD48Zm9udCBzaXplPSIyIj6157uwo7pfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPrSr1eajul9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+RS1tYWlso7pfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPjwvZm9udD48L3RkPjwvdHI+PHRyPjx0ZCBoZWlnaHQ9IjEyIiBjb2xzcGFuPSIy IiBhbGlnbj0iTEVGVCI+Jm5ic3A7PC90ZD48L3RyPjx0cj48dGQgaGVpZ2h0PSIxMiIgY29sc3Bh bj0iMiIgYWxpZ249IkxFRlQiPiZuYnNwOzwvdGQ+PC90cj48dHI+PHRkIGhlaWdodD0iMTIiIGNv bHNwYW49IjIiIGFsaWduPSJMRUZUIj4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT48L3RkPjwvdHI+ PHRyPjx0ZD4mbmJzcDs8L3RkPjwvdHI+PHRyPjx0ZD4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT48 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== ------=_NextPart_000_2D8BB_01C10E1F.629A29D0-- From mozart@minastc.com.br Mon Jul 16 17:13:02 2001 From: mozart@minastc.com.br (Mozart Fazito) Date: Mon, 16 Jul 2001 13:13:02 -0300 Subject: [DB-SIG] informixdb Message-ID: <003f01c10e12$30434640$0100020a@minastenis.com.br> This is a multi-part message in MIME format. ------=_NextPart_000_003C_01C10DF9.0ABA8BE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sir, I'm trying to install ZInformixDA in an Linux Computer (RedHat).=20 Then installagion of InformixDB is a pre-requisite for ZInformixDA. All the installation procedures were successfull (Zope 2.3.2, = INFORMIX-Client SDK Version 2.60.UC1, InformixDB 1.3, ZInformixDA = Version 0.2). But, when I try to connect to my database, I receive the following = message: "Fatal Python error: PyThreadState_get: no current thread" I'm a newbie in Python. May you help me? Thanks. Mozart Fazito Rezende ------=_NextPart_000_003C_01C10DF9.0ABA8BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Sir,
 
I'm trying to install ZInformixDA in an = Linux=20 Computer (RedHat).
 
Then installagion of InformixDB is a pre-requisite for = ZInformixDA.
 
All the installation procedures were = successfull=20 (Zope 2.3.2, INFORMIX-Client SDK Version 2.60.UC1, InformixDB 1.3, = ZInformixDA=20 Version 0.2).
 
But, when I try to = connect to my=20 database, I receive the following message:
 
"Fatal Python error: PyThreadState_get: no current thread"
 
I'm a newbie in Python. May you help=20 me?
 
Thanks.
 
Mozart Fazito=20 Rezende
------=_NextPart_000_003C_01C10DF9.0ABA8BE0-- From daniel.dittmar@sap.com Mon Jul 16 17:15:44 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Mon, 16 Jul 2001 18:15:44 +0200 Subject: [DB-SIG] informixdb Message-ID: > But, when I try to connect to my database, I receive the following message: > > "Fatal Python error: PyThreadState_get: no current thread" If you installed a binary version of ZInformixDA: this could be a version mismatch between your Python version and the version ZInformixDA was compiled against. Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From Anthony@COMPUTRONIX.com Tue Jul 17 21:37:24 2001 From: Anthony@COMPUTRONIX.com (Anthony Tuininga) Date: Tue, 17 Jul 2001 14:37:24 -0600 Subject: [DB-SIG] cx_Oracle 2.2 Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10F00.49711950 Content-Type: text/plain; charset="iso-8859-1" I am pleased to announce a new version of cx_Oracle, a Python DB-API 2.0 compliant interface module. The changes are as follows.... Changes from 2.1 to 2.2 1) Upgraded thread safety to level 1 (according to the Python DB API 2.0) as an internal project required the ability to share the module between threads. 2) Added ability to bind ref cursors to PL/SQL blocks as requested by Brad Powell. 3) Added function write(Value, [Offset]) to LOB variables as requested by Matthias Kirst. 4) Procedure execute() on Cursor objects now permits a value None for the statement which means that the previously prepared statement will be executed and any input sizes set earlier will be retained. This was done to improve the performance of scripts that execute one statement many times. 5) Modified module global constants BINARY and DATETIME to point to the external representations of those types so that the expression type(var) == cx_Oracle.DATETIME will work as expected. 6) Added global constant version to provide means of determining the current version of the module. 7) Modified error checking routine to distinguish between an Oracle error and invalid handles. 8) Added error checking to avoid setting the value of a bind variable to a value that it cannot support and raised an exception to indicate this fact. 9) Added extra compile arguments for the AIX platform as suggested by Jehwan Ryu. 10) Added section to the README to indicate the method for a binary installation as suggested by Steve Holden. 11) Added simple usage example as requested by many people. 12) Added HISTORY file to the distribution. If there are any comments please feel free to write to me at anthony@computronix.com. Thanks. Anthony Tuininga ------_=_NextPart_001_01C10F00.49711950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable cx_Oracle 2.2

I am pleased to announce a new version = of cx_Oracle, a Python DB-API 2.0 compliant interface module. The = changes are as follows....

Changes from 2.1 to 2.2

 1) Upgraded thread safety to = level 1 (according to the Python DB API 2.0) as
    an internal = project required the ability to share the module between
    threads.
 2) Added ability to bind ref = cursors to PL/SQL blocks as requested by
    Brad = Powell.
 3) Added function write(Value, = [Offset]) to LOB variables as requested by
    Matthias = Kirst.
 4) Procedure execute() on = Cursor objects now permits a value None for the
    statement which = means that the previously prepared statement will be
    executed and any = input sizes set earlier will be retained. This was done to
    improve the = performance of scripts that execute one statement many times.
 5) Modified module global = constants BINARY and DATETIME to point to the
    external = representations of those types so that the expression
    type(var) =3D=3D = cx_Oracle.DATETIME will work as expected.
 6) Added global constant = version to provide means of determining the current
    version of the = module.
 7) Modified error checking = routine to distinguish between an Oracle error and
    invalid = handles.
 8) Added error checking to = avoid setting the value of a bind variable to a
    value that it = cannot support and raised an exception to indicate this fact.
 9) Added extra compile = arguments for the AIX platform as suggested by Jehwan
    Ryu.
10) Added section to the README to = indicate the method for a binary
    installation as = suggested by Steve Holden.
11) Added simple usage example as = requested by many people.
12) Added HISTORY file to the = distribution.

If there are any comments please feel = free to write to me at anthony@computronix.com. Thanks.

Anthony Tuininga

------_=_NextPart_001_01C10F00.49711950-- From Anthony@COMPUTRONIX.com Tue Jul 17 21:39:26 2001 From: Anthony@COMPUTRONIX.com (Anthony Tuininga) Date: Tue, 17 Jul 2001 14:39:26 -0600 Subject: [DB-SIG] cx_Oracle 2.2 [Amended] Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10F00.920E9390 Content-Type: text/plain; charset="iso-8859-1" Please excuse the extra announcement. I forgot to mention the download location. Oops! I am pleased to announce a new version of cx_Oracle, a Python DB-API 2.0 compliant interface module. Download from www.computronix.com/utilities Changes from 2.1 to 2.2 1) Upgraded thread safety to level 1 (according to the Python DB API 2.0) as an internal project required the ability to share the module between threads. 2) Added ability to bind ref cursors to PL/SQL blocks as requested by Brad Powell. 3) Added function write(Value, [Offset]) to LOB variables as requested by Matthias Kirst. 4) Procedure execute() on Cursor objects now permits a value None for the statement which means that the previously prepared statement will be executed and any input sizes set earlier will be retained. This was done to improve the performance of scripts that execute one statement many times. 5) Modified module global constants BINARY and DATETIME to point to the external representations of those types so that the expression type(var) == cx_Oracle.DATETIME will work as expected. 6) Added global constant version to provide means of determining the current version of the module. 7) Modified error checking routine to distinguish between an Oracle error and invalid handles. 8) Added error checking to avoid setting the value of a bind variable to a value that it cannot support and raised an exception to indicate this fact. 9) Added extra compile arguments for the AIX platform as suggested by Jehwan Ryu. 10) Added section to the README to indicate the method for a binary installation as suggested by Steve Holden. 11) Added simple usage example as requested by many people. 12) Added HISTORY file to the distribution. If there are any comments please feel free to write to me at anthony@computronix.com. Thanks. Anthony Tuininga ------_=_NextPart_001_01C10F00.920E9390 Content-Type: text/html; charset="iso-8859-1" cx_Oracle 2.2 [Amended]

Please excuse the extra announcement. I forgot to mention the download location. Oops!

I am pleased to announce a new version of cx_Oracle, a Python DB-API 2.0 compliant interface module.
Download from www.computronix.com/utilities

Changes from 2.1 to 2.2

 1) Upgraded thread safety to level 1 (according to the Python DB API 2.0) as
    an internal project required the ability to share the module between
    threads.
 2) Added ability to bind ref cursors to PL/SQL blocks as requested by
    Brad Powell.
 3) Added function write(Value, [Offset]) to LOB variables as requested by
    Matthias Kirst.
 4) Procedure execute() on Cursor objects now permits a value None for the
    statement which means that the previously prepared statement will be
    executed and any input sizes set earlier will be retained. This was done to
    improve the performance of scripts that execute one statement many times.
 5) Modified module global constants BINARY and DATETIME to point to the
    external representations of those types so that the expression
    type(var) == cx_Oracle.DATETIME will work as expected.
 6) Added global constant version to provide means of determining the current
    version of the module.
 7) Modified error checking routine to distinguish between an Oracle error and
    invalid handles.
 8) Added error checking to avoid setting the value of a bind variable to a
    value that it cannot support and raised an exception to indicate this fact.
 9) Added extra compile arguments for the AIX platform as suggested by Jehwan
    Ryu.
10) Added section to the README to indicate the method for a binary
    installation as suggested by Steve Holden.
11) Added simple usage example as requested by many people.
12) Added HISTORY file to the distribution.

If there are any comments please feel free to write to me at anthony@computronix.com. Thanks.

Anthony Tuininga


------_=_NextPart_001_01C10F00.920E9390-- From djc@object-craft.com.au Wed Jul 18 04:09:33 2001 From: djc@object-craft.com.au (Dave Cole) Date: 18 Jul 2001 13:09:33 +1000 Subject: [DB-SIG] Sybase module 0.30 (Graham Ashton release) released In-Reply-To: Dave Cole's message of "27 Jun 2001 13:05:27 +1000" Message-ID: What is it: The Sybase module provides a Python interface to the Sybase relational database system. It supports all of the Python Database API, version 2.0 with extensions. This is the first release in which the DB-API compliance is as close as it can get with Sybase. There was a recent thread on comp.lang.python where Python database modules were labelled experimental and unsupported. We have decided to label ours as non-experimental and will be offering commercial support from this release. Please refer to our website for details: http://www.object-craft.com.au/support.html For those people who do not have LaTeX installed, there is a PDF version of the package documentation. The PostScript version prints out a handy A5 booklet on an A4 duplex printer. The module and documentation are all available on here: http://www.object-craft.com.au/projects/sybase/ Thanks ------ Many thanks to Graham Ashton for spending time working with me to isolate the dynamic SQL deallocation bug. Changes for this release ------------------------ Bugfixes: 1) Dynamic SQL constructed for cursor is now deallocated. After around 9000 different queries over the same cursor the server was running out of procedure space. 2) ct_con_props() CS_TDS_VERSION is an integer no a string. 3) ct_con_props(), ct_options(), ct_config() were returning string values with trailing nul character. 4) ct_config() CS_VERSION is an integer no a string. 5) Fixed refcount leak in ct_res_info(CS_ORDERBY_COLS) DB-API compliance: 1) Implemented DB-API STRING, BINARY, NUMBER, DATETIME, and ROWID type objects. 2) Implemented DB-API Date(), Timestamp(), DateFromTicks(), TimestampFromTicks(), and Binary() functions. Documentation: 1) Complete DB-API documentation for Sybase.py 2) Low level sybasect extension module now explains how the Sybase API is wrapped - it does not attempt to explain how to use the API. Sybase have excellent documentation which covers that. Documentation for bulkcopy descriptors includes a small program to bulkcopy a table from one server to another using a single set of buffers. 3) Miscellaneous docstring fixups. Improvements and enhancements: 1) All binary dependence on mxDateTime has been removed - it is now integrated at Python level. If mxDateTime is available then datetime columns will be returned as mxDateTime.DateTime objects - otherwise they are returned as internal DateTime objects. You can disable the use of mxDateTime by doing this: import Sybase Sybase.use_datetime = 0 2) Renamed con object in Sybase.py to conn to be consistent with sybasect wrapper module. 3) Reorganised and simplified cursor DB-API state machine in Sybase.py. 4) Wrap all Sybase API functions with checks for exceptions raised by Python callback functions. 5) Added debug, conn, and direction attributes to CS_BLKDESC object. 6) When CS_DATAFMT structures are cleared when initialised - eliminates possibility of unexpected values. 7) Added native Sybase datetime/smalldatetime object. Construct and use these objects like this: >>> import Sybase >>> a = Sybase.money(25.99) >>> type(a) >>> b = a + 5 >>> b 30.99 >>> type(b) >>> b - a 5.00 >>> dt = Sybase.datetime('2001-07-17', Sybase.CS_DATETIME4_TYPE) >>> dt Jul 17 2001 12:00AM >>> type(dt) 8) Added native Sybase money/smallmoney object. 9) DataBuf objects can autoconvert values to money and numeric values during assignment. -- http://www.object-craft.com.au From mal@lemburg.com Fri Jul 20 19:07:24 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 20 Jul 2001 20:07:24 +0200 Subject: [DB-SIG] How to handle database warnings ? Message-ID: <3B58735C.7A7A54F0@lemburg.com> I am currently working on a modification to mxODBC which solves the problems users sometimes have with database warnings. Since I think that some other database modules may have the same problem, I would like to get your opinion about this. mxODBC currently converts most warnings from the database into Python exceptions. This sometimes causes failure of more complex operations like e.g. calling stored procedures. To solve this, I've added a list attribute .messages to both connection and cursor objects which will hold the error and warning messages generated by the low-level code in the order they are generated by the database. Errors will still be reported using Python exceptions, but I am planning to drop the exception mechanism for warnings. The latter will then only be available by looking at the .messages list. Now to make this easy and also to avoid the generation of large message lists, I am thinking of auto-clearing the .messages lists after prior to all method calls. This would then enable code like: c.execute(sql) if c.messages: # got some warnings print c.messages for row in c.fetchall(): ... What do you think ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From pshafaee@hostway.com Sun Jul 22 05:29:22 2001 From: pshafaee@hostway.com (John Shafaee) Date: Sat, 21 Jul 2001 23:29:22 -0500 Subject: [DB-SIG] Re: DB-SIG digest, Vol 1 #445 - 1 msg References: Message-ID: <3B5A56A2.67CF272F@hostway.com> I agree with your approach. I wrote my own DB factory class and DB interface wrapper which simply grabs the DB warning exceptions and ignores them (well, it makes note of them silently). THis has worked very well for me and has passed the test of time. It would be great to have this support at a lower level as it will make working with stored procedures a lot easier, as you have already noted. John S 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. How to handle database warnings ? (M.-A. Lemburg) > > ------------------------------------------------------------------------ > > Subject: [DB-SIG] How to handle database warnings ? > Date: Fri, 20 Jul 2001 20:07:24 +0200 > From: "M.-A. Lemburg" > Organization: eGenix.com Software GmbH -- http://www.egenix.com/ > To: "DB-SIG @ Python.org" > > I am currently working on a modification to mxODBC which solves > the problems users sometimes have with database warnings. > Since I think that some other database modules may have the > same problem, I would like to get your opinion about this. > > mxODBC currently converts most warnings from the database > into Python exceptions. This sometimes causes failure of > more complex operations like e.g. calling stored procedures. > > To solve this, I've added a list attribute .messages to both > connection and cursor objects which will hold the error > and warning messages generated by the low-level code in the > order they are generated by the database. Errors will still be > reported using Python exceptions, but I am planning > to drop the exception mechanism for warnings. > > The latter will then only be available by looking at the > .messages list. > > Now to make this easy and also to avoid the generation of > large message lists, I am thinking of auto-clearing the > .messages lists after prior to all method calls. > > This would then enable code like: > > c.execute(sql) > if c.messages: > # got some warnings > print c.messages > for row in c.fetchall(): > ... > > What do you think ? > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Sun Jul 22 13:18:06 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 22 Jul 2001 14:18:06 +0200 Subject: [DB-SIG] Re: How to handle database warnings ? References: <3B5A56A2.67CF272F@hostway.com> Message-ID: <3B5AC47E.F4C5FB10@lemburg.com> John Shafaee wrote: > > I agree with your approach. I wrote my own DB factory class and DB interface > wrapper which simply grabs the DB warning exceptions and ignores them (well, > it makes note of them silently). THis has worked very well for me and has > passed the test of time. > > It would be great to have this support at a lower level as it will make > working with stored procedures a lot easier, as you have already noted. Right, that's the idea. I am only curious about when to clear the list of messages/warnings. Currently, I think that clearing the list prior to all method calls would be a good idea, but I'm not sure whether this would perhaps be to radical... perhaps the list should contain all messages (errors + warnings) which occurred the last .execute() ?! This would make testing for warnings somewhat more difficult though. > John S > > 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. How to handle database warnings ? (M.-A. Lemburg) > > > > ------------------------------------------------------------------------ > > > > Subject: [DB-SIG] How to handle database warnings ? > > Date: Fri, 20 Jul 2001 20:07:24 +0200 > > From: "M.-A. Lemburg" > > Organization: eGenix.com Software GmbH -- http://www.egenix.com/ > > To: "DB-SIG @ Python.org" > > > > I am currently working on a modification to mxODBC which solves > > the problems users sometimes have with database warnings. > > Since I think that some other database modules may have the > > same problem, I would like to get your opinion about this. > > > > mxODBC currently converts most warnings from the database > > into Python exceptions. This sometimes causes failure of > > more complex operations like e.g. calling stored procedures. > > > > To solve this, I've added a list attribute .messages to both > > connection and cursor objects which will hold the error > > and warning messages generated by the low-level code in the > > order they are generated by the database. Errors will still be > > reported using Python exceptions, but I am planning > > to drop the exception mechanism for warnings. > > > > The latter will then only be available by looking at the > > .messages list. > > > > Now to make this easy and also to avoid the generation of > > large message lists, I am thinking of auto-clearing the > > .messages lists after prior to all method calls. > > > > This would then enable code like: > > > > c.execute(sql) > > if c.messages: > > # got some warnings > > print c.messages > > for row in c.fetchall(): > > ... > > > > What do you think ? > > > > -- > > Marc-Andre Lemburg > > CEO eGenix.com Software GmbH > > ______________________________________________________________________ > > Company & Consulting: http://www.egenix.com/ > > Python Software: http://www.lemburg.com/python/ > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From djc@object-craft.com.au Mon Jul 23 01:59:05 2001 From: djc@object-craft.com.au (Dave Cole) Date: 23 Jul 2001 10:59:05 +1000 Subject: [DB-SIG] How to handle database warnings ? In-Reply-To: "M.-A. Lemburg"'s message of "Fri, 20 Jul 2001 20:07:24 +0200" References: <3B58735C.7A7A54F0@lemburg.com> Message-ID: M> I am currently working on a modification to mxODBC which solves the M> problems users sometimes have with database warnings. Since I M> think that some other database modules may have the same problem, I M> would like to get your opinion about this. Processing messages from the database is one of the biggest issues I have with my Sybase module. There are a huge number of different messages that the API can generate. M> mxODBC currently converts most warnings from the database M> into Python exceptions. This sometimes causes failure of M> more complex operations like e.g. calling stored procedures. I have been considering taking this approach with my Sybase module but I am a bit concerned that I might end up raising an exception when I shouldn't, or not raising an exception when I should... M> To solve this, I've added a list attribute .messages to both M> connection and cursor objects which will hold the error M> and warning messages generated by the low-level code in the M> order they are generated by the database. Errors will still be M> reported using Python exceptions, but I am planning M> to drop the exception mechanism for warnings. The Sybase API allows you to handle messages in two way; inline, or by callback. I have taken the option of handling them inline. Each time I make a call to the API I check the return result. If the function fails I then go and retrieve all of the messages from the API and turn them into an exception. This simplistic approach has the advantage that I only ever raise an exception when something fails - I automatically ignore the information messages. I feel that the callback method is a better technical solution. The only problem is that I would have to start interpreting the messages myself to decide whether or not to raise an exception. Or maybe not... If I used your suggestion, I could accumulate the messages in the connection via callback, then raise an exception when an API call failed. This is definitely something worth investigating. - - Slight diversion - - - - - - - - - - - - - - - - - - - - - - - - - The callback option raises an issue which I discovered while testing callbacks in my low level extension module. I will have to drop into code for a while to explain this... A (slightly edited) proto-typical API wrapper in my code looks like this: PyErr_Clear(); SY_BEGIN_THREADS; status = ct_cmd_drop(self->cmd); SY_END_THREADS; if (PyErr_Occurred()) return NULL; Before I call the Sybase API I clear the Python error indicator. After calling the API I check the error indicator to see if a callback function has raised an exception. The other lines of code SY_BEGIN_THREADS; SY_END_THREADS; Are simple macros which allow me to turn Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS into compile time options. The interesting thing that I noticed was that when I enabled the option which releases the global interpreter lock while an API is being called, the program segfaulted inside the callback function. I understood this to mean that you must guarantee that the interpreter will not be re-entered if you release the global lock. I did find some documentation which seemed to support this conclusion. Currently I am compiling my module in a way which never releases the interpreter lock to make the callback mechanism available to programs which need to use it. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - M> The latter will then only be available by looking at the M> .messages list. To be able to leave warnings in the connection, I suppose I am going to have to bite the bullet and start looking at the message codes... M> Now to make this easy and also to avoid the generation of M> large message lists, I am thinking of auto-clearing the M> .messages lists after prior to all method calls. M> M> This would then enable code like: M> M> c.execute(sql) M> if c.messages: M> # got some warnings M> print c.messages M> for row in c.fetchall(): M> ... M> M> What do you think ? I think it is an excellent idea. In my opinion it should be added to the DB-API, although maybe as an implementation option. - Dave -- http://www.object-craft.com.au From fog@mixadlive.com Mon Jul 23 11:10:23 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Mon, 23 Jul 2001 12:10:23 +0200 Subject: [DB-SIG] How to handle database warnings ? In-Reply-To: Message-ID: <20010723121022.A3425@mixadlive.com> Scavenging the mail folder uncovered Dave Cole's letter: [snip] > M> To solve this, I've added a list attribute .messages to both > M> connection and cursor objects which will hold the error > M> and warning messages generated by the low-level code in the > M> order they are generated by the database. Errors will still be > M> reported using Python exceptions, but I am planning > M> to drop the exception mechanism for warnings. we are about to add the same thing to psycopg. because of the ALLOW_THREADS problem (see below) we *alredy* save errors and check them (raising an exception if necessary) before returning from the invoked method. imo, clearing the wrning/error state before every method invokation is quite right. [snip] > The interesting thing that I noticed was that when I enabled the > option which releases the global interpreter lock while an API is > being called, the program segfaulted inside the callback function. I > understood this to mean that you must guarantee that the interpreter > will not be re-entered if you release the global lock. I did find > some documentation which seemed to support this conclusion. this same problem bited us hard. after releasing the global lock (via the PY_ALLOW_THREADS macro) you should *never* call any Py_ function that changes the interpreter internal status. so you can't create new data, call formatting functions or even raise an exception. we solved this problem by saving the current error in a variable and then checking for it and raising the exception just before exiting the outermost function, outside of any ALLOW_THREADS scope. it worked quite well. my $0.02, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra From dieter@sz-sb.de Mon Jul 23 11:31:33 2001 From: dieter@sz-sb.de (Dr. Dieter Maurer) Date: Mon, 23 Jul 2001 12:31:33 +0200 (CEST) Subject: [DB-SIG] How to handle database warnings ? In-Reply-To: <20010723121022.A3425@mixadlive.com> References: <20010723121022.A3425@mixadlive.com> Message-ID: <15195.64629.163217.582172@dieter.sz-sb.de> Federico Di Gregorio writes: > > The interesting thing that I noticed was that when I enabled the > > option which releases the global interpreter lock while an API is > > being called, the program segfaulted inside the callback function. I > > understood this to mean that you must guarantee that the interpreter > > will not be re-entered if you release the global lock. I did find > > some documentation which seemed to support this conclusion. > > this same problem bited us hard. after releasing the global lock (via > the PY_ALLOW_THREADS macro) you should *never* call any Py_ function > that changes the interpreter internal status. so you can't create new > data, call formatting functions or even raise an exception. we solved > this problem by saving the current error in a variable and then checking > for it and raising the exception just before exiting the outermost function, > outside of any ALLOW_THREADS scope. it worked quite well. An alternative would be to reacquire the global interpreter lock. This would be necessary for callbacks that report status information (something like "15% processed, 20% processed..."). I do not know, whether any relational database systems supports this type of status information. Dieter From fog@mixadlive.com Mon Jul 23 11:37:35 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Mon, 23 Jul 2001 12:37:35 +0200 Subject: [DB-SIG] How to handle database warnings ? In-Reply-To: <15195.64629.163217.582172@dieter.sz-sb.de> Message-ID: <20010723123735.A3534@mixadlive.com> Scavenging the mail folder uncovered Dr. Dieter Maurer's letter: > Federico Di Gregorio writes: [snip] > > this same problem bited us hard. after releasing the global lock (via > > the PY_ALLOW_THREADS macro) you should *never* call any Py_ function > > that changes the interpreter internal status. so you can't create new > > data, call formatting functions or even raise an exception. we solved > > this problem by saving the current error in a variable and then checking > > for it and raising the exception just before exiting the outermost function, > > outside of any ALLOW_THREADS scope. it worked quite well. > An alternative would be to reacquire the global interpreter lock. this is not feasible for us because after releasing the python lock a function can acquire a maximum of two other locks (the connection pool lock and the physical connection lock) and can't reacquire the python one without releasing the others (->deadlock). it is much simplier to postpone the exception processing than juggle with the locks... > This would be necessary for callbacks that report status information > (something like "15% processed, 20% processed..."). > I do not know, whether any relational database systems supports > this type of status information. that would be nice, but i don't know of any db supporting it. ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org I came like Water, and like Wind I go. -- O. Khayam From pshafaee@hostway.com Mon Jul 23 15:19:43 2001 From: pshafaee@hostway.com (John Shafaee) Date: Mon, 23 Jul 2001 09:19:43 -0500 Subject: [DB-SIG] Re: How to handle database warnings ? References: <3B5A56A2.67CF272F@hostway.com> <3B5AC47E.F4C5FB10@lemburg.com> Message-ID: <3B5C327F.149F5F75@hostway.net> I am personally in favor of clearing the list after each call to execute(). This allows the programmer ample opportunity to make note of the list contents if so desired. The semantics of clearing after a call to execute() is also more clear and intuitive. You can optionally add an extra method that can be used to flush the error/warning queue on demand. "M.-A. Lemburg" wrote: > John Shafaee wrote: > > > > I agree with your approach. I wrote my own DB factory class and DB interface > > wrapper which simply grabs the DB warning exceptions and ignores them (well, > > it makes note of them silently). THis has worked very well for me and has > > passed the test of time. > > > > It would be great to have this support at a lower level as it will make > > working with stored procedures a lot easier, as you have already noted. > > Right, that's the idea. I am only curious about when to clear the > list of messages/warnings. Currently, I think that clearing the list > prior to all method calls would be a good idea, but I'm not sure > whether this would perhaps be to radical... perhaps the list should > contain all messages (errors + warnings) which occurred the last > .execute() ?! > > This would make testing for warnings somewhat more difficult though. > > > John S > > > > 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. How to handle database warnings ? (M.-A. Lemburg) > > > > > > ------------------------------------------------------------------------ > > > > > > Subject: [DB-SIG] How to handle database warnings ? > > > Date: Fri, 20 Jul 2001 20:07:24 +0200 > > > From: "M.-A. Lemburg" > > > Organization: eGenix.com Software GmbH -- http://www.egenix.com/ > > > To: "DB-SIG @ Python.org" > > > > > > I am currently working on a modification to mxODBC which solves > > > the problems users sometimes have with database warnings. > > > Since I think that some other database modules may have the > > > same problem, I would like to get your opinion about this. > > > > > > mxODBC currently converts most warnings from the database > > > into Python exceptions. This sometimes causes failure of > > > more complex operations like e.g. calling stored procedures. > > > > > > To solve this, I've added a list attribute .messages to both > > > connection and cursor objects which will hold the error > > > and warning messages generated by the low-level code in the > > > order they are generated by the database. Errors will still be > > > reported using Python exceptions, but I am planning > > > to drop the exception mechanism for warnings. > > > > > > The latter will then only be available by looking at the > > > .messages list. > > > > > > Now to make this easy and also to avoid the generation of > > > large message lists, I am thinking of auto-clearing the > > > .messages lists after prior to all method calls. > > > > > > This would then enable code like: > > > > > > c.execute(sql) > > > if c.messages: > > > # got some warnings > > > print c.messages > > > for row in c.fetchall(): > > > ... > > > > > > What do you think ? > > > > > > -- > > > Marc-Andre Lemburg > > > CEO eGenix.com Software GmbH > > > ______________________________________________________________________ > > > Company & Consulting: http://www.egenix.com/ > > > Python Software: http://www.lemburg.com/python/ > > > > _______________________________________________ > > DB-SIG maillist - DB-SIG@python.org > > http://mail.python.org/mailman/listinfo/db-sig > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Consulting & Company: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ From fog@mixadlive.com Mon Jul 23 15:37:36 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Mon, 23 Jul 2001 16:37:36 +0200 Subject: [DB-SIG] Re: How to handle database warnings ? In-Reply-To: <3B5C327F.149F5F75@hostway.net> Message-ID: <20010723163735.A4737@mixadlive.com> Scavenging the mail folder uncovered John Shafaee's letter: > I am personally in favor of clearing the list after each call to execute(). This > allows the programmer ample opportunity to make note of the list contents if so > desired. The semantics of clearing after a call to execute() is also more clear > and intuitive. You can optionally add an extra method that can be used to flush > the error/warning queue on demand. agreed. -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org A short story: I want you. I love you. I'll miss you. -- Me From Anthony@COMPUTRONIX.com Mon Jul 23 15:42:06 2001 From: Anthony@COMPUTRONIX.com (Anthony Tuininga) Date: Mon, 23 Jul 2001 08:42:06 -0600 Subject: [DB-SIG] Re: How to handle database warnings ? Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11385.A550AB30 Content-Type: text/plain; charset="iso-8859-1" Is there any reason why the Python warning framework would not be used? Other than that it is not available until Python 2.1? The advantage to this method is that it makes use of an existing framework and the users of the module would have more control of which warnings they care to see and which ones they would rather not see; otherwise, the module designer dictates what are warnings and what are exceptions or a new framework (as is being discussed) would need to be developed. Anthony Tuininga -----Original Message----- From: John Shafaee [mailto:pshafaee@hostway.net] Sent: Monday, July 23, 2001 8:20 AM To: M.-A. Lemburg Cc: db-sig@python.org Subject: Re: [DB-SIG] Re: How to handle database warnings ? I am personally in favor of clearing the list after each call to execute(). This allows the programmer ample opportunity to make note of the list contents if so desired. The semantics of clearing after a call to execute() is also more clear and intuitive. You can optionally add an extra method that can be used to flush the error/warning queue on demand. "M.-A. Lemburg" wrote: > John Shafaee wrote: > > > > I agree with your approach. I wrote my own DB factory class and DB interface > > wrapper which simply grabs the DB warning exceptions and ignores them (well, > > it makes note of them silently). THis has worked very well for me and has > > passed the test of time. > > > > It would be great to have this support at a lower level as it will make > > working with stored procedures a lot easier, as you have already noted. > > Right, that's the idea. I am only curious about when to clear the > list of messages/warnings. Currently, I think that clearing the list > prior to all method calls would be a good idea, but I'm not sure > whether this would perhaps be to radical... perhaps the list should > contain all messages (errors + warnings) which occurred the last > .execute() ?! > > This would make testing for warnings somewhat more difficult though. > > > John S > > > > 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. How to handle database warnings ? (M.-A. Lemburg) > > > > > > ------------------------------------------------------------------------ > > > > > > Subject: [DB-SIG] How to handle database warnings ? > > > Date: Fri, 20 Jul 2001 20:07:24 +0200 > > > From: "M.-A. Lemburg" > > > Organization: eGenix.com Software GmbH -- http://www.egenix.com/ > > > To: "DB-SIG @ Python.org" > > > > > > I am currently working on a modification to mxODBC which solves > > > the problems users sometimes have with database warnings. > > > Since I think that some other database modules may have the > > > same problem, I would like to get your opinion about this. > > > > > > mxODBC currently converts most warnings from the database > > > into Python exceptions. This sometimes causes failure of > > > more complex operations like e.g. calling stored procedures. > > > > > > To solve this, I've added a list attribute .messages to both > > > connection and cursor objects which will hold the error > > > and warning messages generated by the low-level code in the > > > order they are generated by the database. Errors will still be > > > reported using Python exceptions, but I am planning > > > to drop the exception mechanism for warnings. > > > > > > The latter will then only be available by looking at the > > > .messages list. > > > > > > Now to make this easy and also to avoid the generation of > > > large message lists, I am thinking of auto-clearing the > > > .messages lists after prior to all method calls. > > > > > > This would then enable code like: > > > > > > c.execute(sql) > > > if c.messages: > > > # got some warnings > > > print c.messages > > > for row in c.fetchall(): > > > ... > > > > > > What do you think ? > > > > > > -- > > > Marc-Andre Lemburg > > > CEO eGenix.com Software GmbH > > > ______________________________________________________________________ > > > Company & Consulting: http://www.egenix.com/ > > > Python Software: http://www.lemburg.com/python/ > > > > _______________________________________________ > > DB-SIG maillist - DB-SIG@python.org > > http://mail.python.org/mailman/listinfo/db-sig > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Consulting & Company: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig ------_=_NextPart_001_01C11385.A550AB30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [DB-SIG] Re: How to handle database warnings ?

Is there any reason why the Python warning framework = would not be used? Other than that it is not available until Python = 2.1? The advantage to this method is that it makes use of an existing = framework and the users of the module would have more control of which = warnings they care to see and which ones they would rather not see; = otherwise, the module designer dictates what are warnings and what are = exceptions or a new framework (as is being discussed) would need to be = developed.

Anthony Tuininga

-----Original Message-----
From: John Shafaee [mailto:pshafaee@hostway.net]
Sent: Monday, July 23, 2001 8:20 AM
To: M.-A. Lemburg
Cc: db-sig@python.org
Subject: Re: [DB-SIG] Re: How to handle database = warnings ?


I am personally in favor of clearing the list after = each call to execute(). This
allows the programmer ample opportunity to make note = of the list contents if so
desired. The semantics of clearing after a call to = execute() is also more clear
and intuitive. You can optionally add an extra = method that can be used to flush
the error/warning queue on demand.

"M.-A. Lemburg" wrote:

> John Shafaee wrote:
> >
> > I agree with your approach. I wrote my own = DB factory class and DB interface
> > wrapper which simply grabs the DB warning = exceptions and ignores them (well,
> > it makes note of them silently). THis has = worked very well for me and has
> > passed the test of time.
> >
> > It would be great to have this support at = a lower level as it will make
> > working with stored procedures a lot = easier, as you have already noted.
>
> Right, that's the idea. I am only curious about = when to clear the
> list of messages/warnings. Currently, I think = that clearing the list
> prior to all method calls would be a good idea, = but I'm not sure
> whether this would perhaps be to radical... = perhaps the list should
> contain all messages (errors + warnings) which = occurred the last
> .execute() ?!
>
> This would make testing for warnings somewhat = more difficult though.
>
> > John S
> >
> > 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. How to handle = database warnings ? (M.-A. Lemburg)
> > >
> > >   = ------------------------------------------------------------------------=
> > >
> > > Subject: [DB-SIG] How to handle = database warnings ?
> > > Date: Fri, 20 Jul 2001 20:07:24 = +0200
> > > From: "M.-A. Lemburg" = <mal@lemburg.com>
> > > Organization: eGenix.com Software = GmbH -- http://www.egenix.com/
> > > To: "DB-SIG @ Python.org" = <db-sig@python.org>
> > >
> > > I am currently working on a = modification to mxODBC which solves
> > > the problems users sometimes have = with database warnings.
> > > Since I think that some other = database modules may have the
> > > same problem, I would like to get = your opinion about this.
> > >
> > > mxODBC currently converts most = warnings from the database
> > > into Python exceptions. This = sometimes causes failure of
> > > more complex operations like e.g. = calling stored procedures.
> > >
> > > To solve this, I've added a list = attribute .messages to both
> > > connection and cursor objects which = will hold the error
> > > and warning messages generated by the = low-level code in the
> > > order they are generated by the = database. Errors will still be
> > > reported using Python exceptions, but = I am planning
> > > to drop the exception mechanism for = warnings.
> > >
> > > The latter will then only be = available by looking at the
> > > .messages list.
> > >
> > > Now to make this easy and also to = avoid the generation of
> > > large message lists, I am thinking of = auto-clearing the
> > > .messages lists after prior to all = method calls.
> > >
> > > This would then enable code = like:
> > >
> > >    c.execute(sql)
> > >    if = c.messages:
> > >       # = got some warnings
> > >       = print c.messages
> > >    for row in = c.fetchall():
> > >       = ...
> > >
> > > What do you think ?
> > >
> > > --
> > > Marc-Andre Lemburg
> > > CEO eGenix.com Software GmbH
> > > = ______________________________________________________________________
> > > Company & = Consulting:          &= nbsp;           &= nbsp;    http://www.egenix.com/
> > > Python = Software:          &nb= sp;           &nb= sp; http://www.lemburg.com/python/
> >
> > = _______________________________________________
> > DB-SIG maillist  -  = DB-SIG@python.org
> > http://mail.python.org/mailman/listinfo/db-sig
>
> --
> Marc-Andre Lemburg
> CEO eGenix.com Software GmbH
> = ______________________________________________________________________
> Consulting & = Company:          &nbs= p;           &nbs= p;    http://www.egenix.com/
> Python = Software:          &nb= sp;           &nb= sp; http://www.lemburg.com/python/


_______________________________________________
DB-SIG maillist  -  = DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig

------_=_NextPart_001_01C11385.A550AB30-- From moored@reed.edu Tue Jul 24 05:38:28 2001 From: moored@reed.edu (moored@reed.edu) Date: Mon, 23 Jul 2001 21:38:28 -0700 (PDT) Subject: [DB-SIG] SQL string escape function Message-ID: Forgive my ignorance and inability to find a manual: Is there a function that will escape special characters from a string such that it can be included in a SQL statement? I'm looking for something like the php AddSlashes(). -------===Dustin Moore===--------- From mal@lemburg.com Tue Jul 24 09:37:50 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 24 Jul 2001 10:37:50 +0200 Subject: [DB-SIG] Re: How to handle database warnings ? References: <3B5A56A2.67CF272F@hostway.com> <3B5AC47E.F4C5FB10@lemburg.com> <3B5C327F.149F5F75@hostway.net> Message-ID: <3B5D33DE.1FB8E576@lemburg.com> John Shafaee wrote: > > I am personally in favor of clearing the list after each call to execute(). This > allows the programmer ample opportunity to make note of the list contents if so > desired. The semantics of clearing after a call to execute() is also more clear > and intuitive. You can optionally add an extra method that can be used to flush > the error/warning queue on demand. Are you sure that you want to clear the list *after* the call and not before processing it ? Also what is your rational for only doing this for the .execute() calls and not the .fetch() calls ? > "M.-A. Lemburg" wrote: > > > John Shafaee wrote: > > > > > > I agree with your approach. I wrote my own DB factory class and DB interface > > > wrapper which simply grabs the DB warning exceptions and ignores them (well, > > > it makes note of them silently). THis has worked very well for me and has > > > passed the test of time. > > > > > > It would be great to have this support at a lower level as it will make > > > working with stored procedures a lot easier, as you have already noted. > > > > Right, that's the idea. I am only curious about when to clear the > > list of messages/warnings. Currently, I think that clearing the list > > prior to all method calls would be a good idea, but I'm not sure > > whether this would perhaps be to radical... perhaps the list should > > contain all messages (errors + warnings) which occurred the last > > .execute() ?! > > > > This would make testing for warnings somewhat more difficult though. > > > > > John S > > > > > > 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. How to handle database warnings ? (M.-A. Lemburg) > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > Subject: [DB-SIG] How to handle database warnings ? > > > > Date: Fri, 20 Jul 2001 20:07:24 +0200 > > > > From: "M.-A. Lemburg" > > > > Organization: eGenix.com Software GmbH -- http://www.egenix.com/ > > > > To: "DB-SIG @ Python.org" > > > > > > > > I am currently working on a modification to mxODBC which solves > > > > the problems users sometimes have with database warnings. > > > > Since I think that some other database modules may have the > > > > same problem, I would like to get your opinion about this. > > > > > > > > mxODBC currently converts most warnings from the database > > > > into Python exceptions. This sometimes causes failure of > > > > more complex operations like e.g. calling stored procedures. > > > > > > > > To solve this, I've added a list attribute .messages to both > > > > connection and cursor objects which will hold the error > > > > and warning messages generated by the low-level code in the > > > > order they are generated by the database. Errors will still be > > > > reported using Python exceptions, but I am planning > > > > to drop the exception mechanism for warnings. > > > > > > > > The latter will then only be available by looking at the > > > > .messages list. > > > > > > > > Now to make this easy and also to avoid the generation of > > > > large message lists, I am thinking of auto-clearing the > > > > .messages lists after prior to all method calls. > > > > > > > > This would then enable code like: > > > > > > > > c.execute(sql) > > > > if c.messages: > > > > # got some warnings > > > > print c.messages > > > > for row in c.fetchall(): > > > > ... > > > > > > > > What do you think ? > > > > > > > > -- > > > > Marc-Andre Lemburg > > > > CEO eGenix.com Software GmbH > > > > ______________________________________________________________________ > > > > Company & Consulting: http://www.egenix.com/ > > > > Python Software: http://www.lemburg.com/python/ > > > > > > _______________________________________________ > > > DB-SIG maillist - DB-SIG@python.org > > > http://mail.python.org/mailman/listinfo/db-sig > > > > -- > > Marc-Andre Lemburg > > CEO eGenix.com Software GmbH > > ______________________________________________________________________ > > Consulting & Company: http://www.egenix.com/ > > Python Software: http://www.lemburg.com/python/ -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Tue Jul 24 09:42:50 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 24 Jul 2001 10:42:50 +0200 Subject: [DB-SIG] Re: How to handle database warnings ? References: Message-ID: <3B5D350A.C6A742E0@lemburg.com> > Anthony Tuininga wrote: > > Is there any reason why the Python warning framework would not be > used? Other than that it is not available until Python 2.1? The > advantage to this method is that it makes use of an existing framework > and the users of the module would have more control of which warnings > they care to see and which ones they would rather not see; otherwise, > the module designer dictates what are warnings and what are exceptions > or a new framework (as is being discussed) would need to be developed. The warning framework in Python 2.1 and later is not fine-grained enough to track down warnings/errors on a per cursor basis. It was designed to warn about source code related warnings, not object based ones (e.g. it includes information about the source file, line number, etc. of where the warning originated). Apart from not being available in Python 1.5.2 (which I still support) this makes it too coarse for the tasks I have in mind. Thanks for the hint though, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Tue Jul 24 10:58:47 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 24 Jul 2001 11:58:47 +0200 Subject: [DB-SIG] SQL string escape function References: Message-ID: <3B5D46D7.3BF2F6B6@lemburg.com> moored@reed.edu wrote: > > Forgive my ignorance and inability to find a manual: Is there a function > that will escape special characters from a string such that it can be > included in a SQL statement? I'm looking for something like the php > AddSlashes(). You normally don't need to do that since the database module will apply the necessary quoting itself if you pass your parameters using bound variables: cursor.execute('select name from mytable where id=?', (id,)) For more infos, please see the database topic guide on www.python.org. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From fog@mixadlive.com Tue Jul 24 11:10:58 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: 24 Jul 2001 12:10:58 +0200 Subject: [DB-SIG] Re: How to handle database warnings ? In-Reply-To: <3B5D33DE.1FB8E576@lemburg.com> References: <3B5A56A2.67CF272F@hostway.com> <3B5AC47E.F4C5FB10@lemburg.com> <3B5C327F.149F5F75@hostway.net> <3B5D33DE.1FB8E576@lemburg.com> Message-ID: <995969459.3108.7.camel@lola> On 24 Jul 2001 10:37:50 +0200, M.-A. Lemburg wrote: > John Shafaee wrote: > > > > I am personally in favor of clearing the list after each call to execute(). This > > allows the programmer ample opportunity to make note of the list contents if so > > desired. The semantics of clearing after a call to execute() is also more clear > > and intuitive. You can optionally add an extra method that can be used to flush > > the error/warning queue on demand. > > Are you sure that you want to clear the list *after* the call and > not before processing it ? imho, this was a typo. the list should be cleared before: if you clear it after, how can the user know what happened during the .execute()? > Also what is your rational for only doing this for the .execute() > calls and not the .fetch() calls ? maybe the user wants to cycle over a bunch of .fetchone() and simply collect all the warnings at the end. also, usually most of the work (and the warnings) are in the execute... -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org All'inizio ho scritto un programma proprietario, in esclusiva per il cliente; e mi ha succhiato un pezzo di anima. -- Alessandro Rubini From mal@lemburg.com Tue Jul 24 12:14:29 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 24 Jul 2001 13:14:29 +0200 Subject: [DB-SIG] Re: How to handle database warnings ? References: <3B5A56A2.67CF272F@hostway.com> <3B5AC47E.F4C5FB10@lemburg.com> <3B5C327F.149F5F75@hostway.net> <3B5D33DE.1FB8E576@lemburg.com> <995969459.3108.7.camel@lola> Message-ID: <3B5D5895.FB74F22D@lemburg.com> Federico Di Gregorio wrote: > > On 24 Jul 2001 10:37:50 +0200, M.-A. Lemburg wrote: > > John Shafaee wrote: > > > > > > I am personally in favor of clearing the list after each call to execute(). This > > > allows the programmer ample opportunity to make note of the list contents if so > > > desired. The semantics of clearing after a call to execute() is also more clear > > > and intuitive. You can optionally add an extra method that can be used to flush > > > the error/warning queue on demand. > > > > Are you sure that you want to clear the list *after* the call and > > not before processing it ? > > imho, this was a typo. the list should be cleared before: if you clear > it after, how can the user know what happened during the .execute()? Right. > > Also what is your rational for only doing this for the .execute() > > calls and not the .fetch() calls ? > > maybe the user wants to cycle over a bunch of .fetchone() and simply > collect all the warnings at the end. also, usually most of the work (and > the warnings) are in the execute... True, even though some .fetchXXX() calls may issue warnings due to data truncation. Ok, so now we know what to do about cursors: the message list should be cleared prior to all method calls which execute a database command (.executeXXX() and catalog methods if they are available). Note that the message list should be clearable using del cursor.messages[:] (I don't think this poses much of a problem if a standard Python list is used). Now what about the connection object and messages generated during connection object creation ? I have a feeling that connection objects should automatically clear messages when entering any of the standard connection object methods. Messages created during connection creation will then be available in the connection.messages list after creation. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From kjcole@gri.gallaudet.edu Tue Jul 24 13:01:53 2001 From: kjcole@gri.gallaudet.edu (Kevin Cole) Date: Tue, 24 Jul 2001 08:01:53 -0400 (EDT) Subject: [DB-SIG] SQL string escape function In-Reply-To: Message-ID: There might be a nice SQL-ish way to do it, but another way to do it is to pass all your strings through Python's regular expression module "re". The following takes a list that may or may not contain string elements and replaces any of the special characters between the single quotes in the re..compile() with the same string surrounded by double quote marks. (It first checks to see if the a is a string, and if the function was called with "lout" as the format argument.) ----------------------------------------------------------------------------- import types import re # Reg exp module quotable = re.compile(r'([/|&{}#@^~\\]+)') # Lout special chars def escape(row,format): if format == "lout": # Format for Lout? for col in range(len(row)): # Check each element if type(row[col]) == types.StringType: # Is it a string? row[col] = quotable.sub(r'"\1"',row[col]) # Substitute ----------------------------------------------------------------------------- For documentation on use, see the Regular Expression HOWTO at: http://py-howto.sourceforge.net/ Hope this helps you... On Mon, 23 Jul 2001 moored@reed.edu wrote: > Forgive my ignorance and inability to find a manual: Is there a function > that will escape special characters from a string such that it can be > included in a SQL statement? I'm looking for something like the php > AddSlashes(). > > -------===Dustin Moore===--------- > > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > -- Kevin Cole, RHCE, Linux Admin | E-mail: kjcole@gri.gallaudet.edu Gallaudet Research Institute | WWW: http://gri.gallaudet.edu/~kjcole/ Hall Memorial Bldg S-419 | Voice: (202) 651-5135 Washington, D.C. 20002-3695 | FAX: (202) 651-5746 From kjcole@gri.gallaudet.edu Tue Jul 24 13:20:19 2001 From: kjcole@gri.gallaudet.edu (Kevin Cole) Date: Tue, 24 Jul 2001 08:20:19 -0400 (EDT) Subject: [DB-SIG] SQL string escape function In-Reply-To: Message-ID: P.S. The description I sent isn't 100% accurate: The compiled regular expression r'([/|&{}#@^~\\]+)' is read "any number of instances of the characters /, |, &, {, }, #, @, ^, ~, or \". The paren- thesis, square brackets and plus are part of the reg exp language. (The r'...' is the syntax for a python raw string.) On Tue, 24 Jul 2001, Kevin Cole wrote: > There might be a nice SQL-ish way to do it, but another way to do it is > to pass all your strings through Python's regular expression module > "re". The following takes a list that may or may not contain string > elements and replaces any of the special characters between the > single quotes in the re..compile() with the same string surrounded by > double quote marks. (It first checks to see if the a is a string, and > if the function was called with "lout" as the format argument.) > ----------------------------------------------------------------------------- > import types > import re # Reg exp module > quotable = re.compile(r'([/|&{}#@^~\\]+)') # Lout special chars > > def escape(row,format): > if format == "lout": # Format for Lout? > for col in range(len(row)): # Check each element > if type(row[col]) == types.StringType: # Is it a string? > row[col] = quotable.sub(r'"\1"',row[col]) # Substitute > ----------------------------------------------------------------------------- > > For documentation on use, see the Regular Expression HOWTO at: > > http://py-howto.sourceforge.net/ > > Hope this helps you... > > On Mon, 23 Jul 2001 moored@reed.edu wrote: > > > Forgive my ignorance and inability to find a manual: Is there a function > > that will escape special characters from a string such that it can be > > included in a SQL statement? I'm looking for something like the php > > AddSlashes(). > > > > -------===Dustin Moore===--------- > > > > > > > > _______________________________________________ > > DB-SIG maillist - DB-SIG@python.org > > http://mail.python.org/mailman/listinfo/db-sig > > > > -- Kevin Cole, RHCE, Linux Admin | E-mail: kjcole@gri.gallaudet.edu Gallaudet Research Institute | WWW: http://gri.gallaudet.edu/~kjcole/ Hall Memorial Bldg S-419 | Voice: (202) 651-5135 Washington, D.C. 20002-3695 | FAX: (202) 651-5746 From Kristen_Blanco@prenhall.com Tue Jul 24 14:38:08 2001 From: Kristen_Blanco@prenhall.com (Kristen_Blanco@prenhall.com) Date: 24 Jul 2001 09:38:08 -0400 Subject: [DB-SIG] Seeking Technical Reviewers for Python Message-ID: <"/GUID:Qz8egeTSA1RGZOABgCI2PYQ*/G=Kristen/S=Blanco/OU=exchange/O=pearsontc/PRMD=pearson/ADMD=telemail/C=us/"@MHS> am writing from Prentice Hall publishing and I am seeking reviewers for an upcoming publication. We are one of the largest college textbook publishers in the US. We are publishing a book entitled "Python How to Program" by Harvey and Paul Deitel. They are premier programming language authors, with the best-selling C++ and Java books in the college market place. More information on their suite of publications can be found here: http://www.prenhall.com/deitel We are presently seeking qualified technical reviewers to verify that the Deitels' coverage of Python in their forthcoming book is accurate. In return, we are offering a token honorarium. Might you be willing to participate? If not, could you perhaps suggest a colleague? If you are interested, or have any questions, please contact my colleague, Crissy Statuto, at Crissy_Statuto@prenhall.com Thank you in advance for your assistance and consideration. Sincerely, Crissy Statuto Crissy Statuto Project Manager, Computer Science Prentice Hall One Lake Street- #3F54 Upper Saddle River, NJ 07458 Tel: 201-236-6695 Fax: 201-236-7170 Email: crissy_statuto@prenhall.com From fog@mixadlive.com Tue Jul 24 21:16:00 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: 24 Jul 2001 22:16:00 +0200 Subject: [DB-SIG] Re: How to handle database warnings ? In-Reply-To: <3B5D5895.FB74F22D@lemburg.com> References: <3B5A56A2.67CF272F@hostway.com> <3B5AC47E.F4C5FB10@lemburg.com> <3B5C327F.149F5F75@hostway.net> <3B5D33DE.1FB8E576@lemburg.com> <995969459.3108.7.camel@lola> <3B5D5895.FB74F22D@lemburg.com> Message-ID: <996005761.32192.3.camel@lola> On 24 Jul 2001 13:14:29 +0200, M.-A. Lemburg wrote: [snip] > Now what about the connection object and messages generated during > connection object creation ?=20 >=20 > I have a feeling that connection objects should automatically > clear messages when entering any of the standard connection object > methods. Messages created during connection creation will then be > available in the connection.messages list after creation. i don't see anything bad with that. seems good to me. err.. i agree. :) ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org La felicit=E0 =E8 una tazza di cioccolata calda. Sempre. -- I= o From paul@dubois.ws Tue Jul 24 21:37:45 2001 From: paul@dubois.ws (Paul DuBois) Date: Tue, 24 Jul 2001 15:37:45 -0500 Subject: [DB-SIG] SQL string escape function In-Reply-To: <3B5D46D7.3BF2F6B6@lemburg.com> References: <3B5D46D7.3BF2F6B6@lemburg.com> Message-ID: At 11:58 AM +0200 7/24/01, M.-A. Lemburg wrote: >moored@reed.edu wrote: >> >> Forgive my ignorance and inability to find a manual: Is there a function >> that will escape special characters from a string such that it can be >> included in a SQL statement? I'm looking for something like the php >> AddSlashes(). > >You normally don't need to do that since the database module >will apply the necessary quoting itself if you pass your parameters >using bound variables: > >cursor.execute('select name from mytable where id=?', (id,)) > >For more infos, please see the database topic guide on www.python.org. You need to do it if you want to produce SQL statements for *another* program to execute. > >-- >Marc-Andre Lemburg >CEO eGenix.com Software GmbH >______________________________________________________________________ >Consulting & Company: http://www.egenix.com/ >Python Software: http://www.lemburg.com/python/ From moored@reed.edu Wed Jul 25 01:52:29 2001 From: moored@reed.edu (moored@reed.edu) Date: Tue, 24 Jul 2001 17:52:29 -0700 (PDT) Subject: [DB-SIG] SQL string escape function In-Reply-To: Message-ID: On Tue, 24 Jul 2001, Paul DuBois wrote: > > You need to do it if you want to produce SQL statements for *another* > program to execute. > I'm not familar with 'bound variables,' but I did search for it. My main wonder is if the two following statements equivalent: sqlstring = "SELECT * FROM table WHERE table.string=\'%s\'" sqlstring = sqlstring % (nastystring) cursor.execute(sql) versus: cursor.execute("SELECT * FROM table WHERE table.string=\'%s\'" % (naststring)) I like to build SQL line by line and cramming the whole expression inside the execute is inconvenient. -------===Dustin Moore===--------- From fog@mixadlive.com Wed Jul 25 08:30:11 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: 25 Jul 2001 09:30:11 +0200 Subject: [DB-SIG] SQL string escape function In-Reply-To: References: Message-ID: <996046212.3175.2.camel@lola> On 24 Jul 2001 17:52:29 -0700, moored@reed.edu wrote: > On Tue, 24 Jul 2001, Paul DuBois wrote: > > > > You need to do it if you want to produce SQL statements for *another* > > program to execute. > > > > I'm not familar with 'bound variables,' but I did search for it. > My main wonder is if the two following statements equivalent: > > sqlstring = "SELECT * FROM table WHERE table.string=\'%s\'" > sqlstring = sqlstring % (nastystring) > cursor.execute(sql) > > versus: > > cursor.execute("SELECT * FROM table WHERE table.string=\'%s\'" % > (naststring)) you don't have to put the ' around %s, the module will do it for you. as somebody other noted in a past thread, letting the module quote the string will improve the security agains nasty-strings attacks, see the ml archives for full explanation and example. oh, also, you' don't have to escape ' inside a " in python. ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Abandon the search for Truth; settle for a good fantasy. -- Anonymous From mal@lemburg.com Wed Jul 25 08:44:41 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 25 Jul 2001 09:44:41 +0200 Subject: [DB-SIG] SQL string escape function References: <3B5D46D7.3BF2F6B6@lemburg.com> Message-ID: <3B5E78E9.33616F78@lemburg.com> Paul DuBois wrote: > > At 11:58 AM +0200 7/24/01, M.-A. Lemburg wrote: > >moored@reed.edu wrote: > >> > >> Forgive my ignorance and inability to find a manual: Is there a function > >> that will escape special characters from a string such that it can be > >> included in a SQL statement? I'm looking for something like the php > >> AddSlashes(). > > > >You normally don't need to do that since the database module > >will apply the necessary quoting itself if you pass your parameters > >using bound variables: > > > >cursor.execute('select name from mytable where id=?', (id,)) > > > >For more infos, please see the database topic guide on www.python.org. > > You need to do it if you want to produce SQL statements for *another* > program to execute. That's true... BTW, there is a dbinfo.py tool on my web-pages which aims at providing standard escaping (and other) mechanism to enable writing cross-database SQL code. Perhaps this module helps ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Wed Jul 25 11:06:22 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 25 Jul 2001 12:06:22 +0200 Subject: [DB-SIG] Re: How to handle database warnings ? References: <3B5A56A2.67CF272F@hostway.com> <3B5AC47E.F4C5FB10@lemburg.com> <3B5C327F.149F5F75@hostway.net> <3B5D33DE.1FB8E576@lemburg.com> <995969459.3108.7.camel@lola> <3B5D5895.FB74F22D@lemburg.com> <996005761.32192.3.camel@lola> Message-ID: <3B5E9A1E.CC094226@lemburg.com> Federico Di Gregorio wrote: > > On 24 Jul 2001 13:14:29 +0200, M.-A. Lemburg wrote: > [snip] > > Now what about the connection object and messages generated during > > connection object creation ? > > > > I have a feeling that connection objects should automatically > > clear messages when entering any of the standard connection object > > methods. Messages created during connection creation will then be > > available in the connection.messages list after creation. > > i don't see anything bad with that. seems good to me. err.. i agree. :) FYI, I've started integrating this into mxODBC. I found that most cursor object methods except the .fetchXXX() APIs will have to implement the automatic message clearing. The .close() method is interesting in this respect: it will clear the list *before* closing the cursor. For the connection object I chose to not implement auto-clearing for the connection option and .getinfo() methods (these are mxODBC specific) since these are likely to be used during warning processing. Also, the message list will include all messages generated by the ODBC driver, not only warnings, but error messages too and it will only store the error object class and value, not the instantiated error object itself (this would be too costly). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From ryanw@inktomi.com Wed Jul 25 21:50:55 2001 From: ryanw@inktomi.com (Ryan Weisenberger) Date: Wed, 25 Jul 2001 13:50:55 -0700 Subject: [DB-SIG] International content Message-ID: <4.3.2.7.2.20010725133046.02819dc0@inkt-3.inktomi.com> I'm still having problems with international character sets in databases. I'm using MS SQL Server 2000, and connecting to it with mxODBC through the 2000 SQL Server ODBC driver. If I have a table with international characters in the table name, here's what happens. I issue: >>> import mxODBC >>> db = mxODBC.Connect('japanese','sa','') >>> c = db.cursor() >>> c.tables(None,None,None,'TABLE') -1 >>> c.fetchall() [('japanese', 'dbo', '?????', 'TABLE', None)] >>> No table name, just question marks. How can I get around this? Where are the characters getting obliterated? Is it in the ODBC driver, or before they ever leave the database? - Ryan _________________________ Ryan Weisenberger Software Developer ryanw@inktomi.com (650) 653-4595 _________________________ From mal@lemburg.com Thu Jul 26 09:23:47 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 26 Jul 2001 10:23:47 +0200 Subject: [DB-SIG] International content References: <4.3.2.7.2.20010725133046.02819dc0@inkt-3.inktomi.com> Message-ID: <3B5FD393.D8336ABA@lemburg.com> Ryan Weisenberger wrote: > > I'm still having problems with international character sets in > databases. I'm using MS SQL Server 2000, and connecting to it with mxODBC > through the 2000 SQL Server ODBC driver. If I have a table with > international characters in the table name, here's what happens. I issue: > > >>> import mxODBC > >>> db = mxODBC.Connect('japanese','sa','') > >>> c = db.cursor() > >>> c.tables(None,None,None,'TABLE') > -1 > >>> c.fetchall() > [('japanese', 'dbo', '?????', 'TABLE', None)] > >>> > > No table name, just question marks. The question marks indicate that the ODBC driver does not know how to convert the Unicode data into the encoding your are using for the connection to the database. I am unsure where the conversion actually happens (in the database, the ODBC driver or the manager), but I was told that you can specify the encoding to be used for the translation using some database parameter. > How can I get around this? Where are > the characters getting obliterated? Is it in the ODBC driver, or before > they ever leave the database? BTW, you should use from mx.ODBC import Windows dbc = Windows.Connect(...) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 26 09:56:12 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 26 Jul 2001 10:56:12 +0200 Subject: [DB-SIG] International content References: <4.3.2.7.2.20010725133046.02819dc0@inkt-3.inktomi.com> <3B5FD393.D8336ABA@lemburg.com> Message-ID: <3B5FDB2C.FABBCCBC@lemburg.com> Here's a reference which might help: http://support.microsoft.com/support/kb/articles/Q257/6/68.ASP "FIX: SQL Server ODBC Driver May Cause Incorrect Code Conversion of Some Characters" -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From i_sofer@yahoo.com Tue Jul 31 08:36:07 2001 From: i_sofer@yahoo.com (Idan Sofer) Date: 31 Jul 2001 10:36:07 +0300 Subject: [DB-SIG] Python-DBCore 0.9(announcment) Message-ID: <200107310755.KAA13210@alpha.netvision.net.il> (Hope it's the right mailing list...) Python-DBCore is a wrapper around Python-DB 2.0 API drivers. Python-DBCore tries to bridge the differences in connection string syntax. Modules importing python-dbcore do not even need to initialize the database. to get a connection, all they have to do is to call DBCore.Factory.Generate(). It also provides a smart and efficent connection pooling system. for read-only requests, it can generate cursors, each time from different connection(it can be done by one connection only if needed) For transactional operations, which need a dedicted channel, it keeps a pool of connections, and creates/destroys connections if empty/full, optionally done in big chunks. It currently supports MySql(by MySQLdb), and Postgres(using Popy or psycopg), however, it shouldn't be too hard to add other databases as well. getting it: http://sstorm.sourceforge.net/python-dbcore-0.9.tar.gz Idan