From wtrenker@shaw.ca Tue Apr 2 01:54:34 2002 From: wtrenker@shaw.ca (William Trenker) Date: Mon, 01 Apr 2002 17:54:34 -0800 Subject: [DB-SIG] SQLite as a Light DB component for Zope and Python Message-ID: <5.1.0.14.0.20020401172813.009f3a80@shawmail> --Boundary_(ID_sAKxc77CcVHeQMPJ/sGIpA) Content-type: multipart/alternative; x-avg-checked=avg-ok-316F626F; boundary="Boundary_(ID_M92ZGiKwF9z7ZfN8kwKFWA)" --Boundary_(ID_M92ZGiKwF9z7ZfN8kwKFWA) Content-type: text/plain; x-avg-checked=avg-ok-316F626F; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT I have noticed on the DB lists lately some concern about the future of Gadfly. I have been investigating a marvelous little open-source, no copyright, SQL engine called SQLite: An SQL Database Engine In A C Library. I am quite experienced with Python, reasonably experienced with Zope but a greenhorn at extending Python yet I had a crude but working Python extension module for SQLite up and running in 2 days (most of that time figuring out the Python extension conventions). I think Python needs a lightweight SQL engine as a standard module, and I think this would be a good Zope product candidate as well. I'm proposing SQLite as that engine. Here is the developer's feature list, taken from the link given above: Implements a large subset of SQL92. A complete database (with multiple tables and indices) is stored in a single disk file. Atomic commit and rollback protect data integrity. Small memory footprint: less than 20K lines of C code. Four times faster than PostgreSQL. Twice as fast as SQLite 1.0. Very simple C/C++ interface requires the use of only three functions and one opaque structure. TCL bindings included. A TCL-based test suite provides near 100% code coverage. Self-contained: no external dependencies. Built and tested under Linux and Win2K. Sources are uncopyrighted. Use for any purpose. The SQLite source code is 35% comment. These comments are another important source of information. The author, D. Richard Hipp, is a computer science Ph.D. who knows his stuff. This is not green software, it is well designed and tested. It was first released in May 2000 and is very actively updated and supported. Thanks for listening. Bill Trenker Internet Applications Developer Kelowna, BC, Canada "The commandments of the LORD are right, bringing joy to the heart. The commands of the LORD are clear, giving insight to life . . . For this is the love of God, that we keep His commandments. And His commandments are not burdensome." (Psalm 19:8, 1John 5:3) torahteacher.com --Boundary_(ID_M92ZGiKwF9z7ZfN8kwKFWA) Content-type: text/html; x-avg-checked=avg-ok-316F626F; charset=us-ascii Content-transfer-encoding: 7BIT I have noticed on the DB lists lately some concern about the future of Gadfly.  I have been investigating a marvelous little open-source, no copyright, SQL engine called SQLite: An SQL Database Engine In A C Library.  I am quite experienced with Python, reasonably experienced with Zope but a greenhorn at extending Python yet I had a crude but working Python extension module for SQLite up and running in 2 days (most of that time figuring out the Python extension conventions).  I think Python needs a lightweight SQL engine as a standard module, and I think this would be a good Zope product candidate as well.  I'm proposing SQLite as that engine.  Here is the developer's feature list, taken from the link given above:

Implements a large subset of SQL92.
A complete database (with multiple tables and indices) is stored in a single disk file.
Atomic commit and rollback protect data integrity.
Small memory footprint: less than 20K lines of C code.
Four times faster than PostgreSQL. Twice as fast as SQLite 1.0.
Very simple C/C++ interface requires the use of only three functions and one opaque structure.
TCL bindings included.
A TCL-based test suite provides near 100% code coverage.
Self-contained: no external dependencies.
Built and tested under Linux and Win2K.
Sources are uncopyrighted. Use for any purpose.
The SQLite source code is 35% comment. These comments are another important source of information.

The author, D. Richard Hipp, is a computer science Ph.D. who knows his stuff.  This is not green software, it is well designed and tested.  It was first released in May 2000 and is very actively updated and supported.

Thanks for listening.

Bill Trenker
Internet Applications Developer
Kelowna, BC, Canada


"The commandments of the LORD are right, bringing joy to the heart. The commands of the LORD are clear, giving insight to life . . . For this is the love of God, that we keep His commandments. And His commandments are not burdensome." (Psalm 19:8, 1John 5:3)    torahteacher.com
 --Boundary_(ID_M92ZGiKwF9z7ZfN8kwKFWA)-- --Boundary_(ID_sAKxc77CcVHeQMPJ/sGIpA) Content-type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-316F626F Content-transfer-encoding: 7BIT Content-disposition: inline --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.343 / Virus Database: 190 - Release Date: 3/22/02 --Boundary_(ID_sAKxc77CcVHeQMPJ/sGIpA)-- From lloyd@lancaster.lib.pa.us Tue Apr 2 15:02:22 2002 From: lloyd@lancaster.lib.pa.us (Eron Lloyd) Date: 02 Apr 2002 10:02:22 -0500 Subject: [DB-SIG] Re: [Zope-dev] SQLite as a Light DB component for Zope and Python In-Reply-To: <5.1.0.14.0.20020401172813.009f3a80@shawmail> References: <5.1.0.14.0.20020401172813.009f3a80@shawmail> Message-ID: <1017759742.1228.7.camel@linux> Very interesting. I think I've read about this somewhere before. The claim of "4x faster than PostgreSQL" raised my brow. It is true that Gadfly is becoming quite stale, and only supports a *very* limited subset of SQL. It also would be nice to see something a bit more robust than just shelve in the Standard Library. Gadfly is ok to begin a prototype in, but frustrating once you quickly hit a glass ceiling in functionality. I'm interested in seeing how well it can scale, versus Postgres, however. Any experience? Thanks for the info, Eron Lloyd On Mon, 2002-04-01 at 20:54, William Trenker wrote: > I have noticed on the DB lists lately some concern about the future of > Gadfly. I have been investigating a marvelous little open-source, no > copyright, SQL engine called > SQLite: An SQL Database Engine > In A C Library. I am quite experienced with Python, reasonably experienced > with Zope but a greenhorn at extending Python yet I had a crude but working > Python extension module for SQLite up and running in 2 days (most of that > time figuring out the Python extension conventions). I think Python needs > a lightweight SQL engine as a standard module, and I think this would be a > good Zope product candidate as well. I'm proposing SQLite as that > engine. Here is the developer's feature list, taken from the link given above: > > Implements a large subset of SQL92. > A complete database (with multiple tables and indices) is stored in a > single disk file. > Atomic commit and rollback protect data integrity. > Small memory footprint: less than 20K lines of C code. > Four times faster than PostgreSQL. Twice as fast as SQLite 1.0. > Very simple C/C++ interface requires the use of only three functions and > one opaque structure. > TCL bindings included. > A TCL-based test suite provides near 100% code coverage. > Self-contained: no external dependencies. > Built and tested under Linux and Win2K. > Sources are uncopyrighted. Use for any purpose. > The SQLite source code is 35% comment. These comments are another important > source of information. > > The author, D. Richard Hipp, is > a computer science Ph.D. who knows his stuff. This is not green software, > it is well designed and tested. It was first released in May 2000 and is > very actively updated and supported. > > Thanks for listening. > > Bill Trenker > Internet Applications Developer > Kelowna, BC, Canada > > > > "The commandments of the LORD are right, bringing joy to the heart. The > commands of the LORD are clear, giving insight to life . . . For this is > the love of God, that we keep His commandments. And His commandments are > not burdensome." (Psalm 19:8, 1John > 5:3) torahteacher.com > > ---- > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.343 / Virus Database: 190 - Release Date: 3/22/02 --- [This E-mail scanned for viruses by Declude Virus] From magnus@thinkware.se Tue Apr 2 23:58:56 2002 From: magnus@thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Wed, 03 Apr 2002 01:58:56 +0200 Subject: [DB-SIG] SQLite as a Light DB component for Zope and Python In-Reply-To: <5.1.0.14.0.20020401172813.009f3a80@shawmail> Message-ID: <5.1.0.14.0.20020403010746.03520a68@mail.irrblosset.se> At 17:54 2002-04-01 -0800, William Trenker wrote: >but a greenhorn at extending Python yet I had a >crude but working Python extension module for >SQLite up and running in 2 days So, we expect to see the announcement of a DB-API 2 complient SQLite driver any day then! :-) >Implements a large subset of SQL92. I'd say a small subset, or perhaps sideset: SQLite implements the follow syntax: =B7 BEGIN TRANSACTION (END COMMIT ROLLBACK) =B7 COPY =B7 CREATE INDEX =B7 CREATE TABLE =B7 CREATE VIEW =B7 DELETE =B7 DROP INDEX =B7 DROP TABLE =B7 DROP VIEW =B7 EXPLAIN =B7 expression =B7 INSERT =B7 ON CONFLICT clause =B7 PRAGMA =B7 REPLACE =B7 SELECT =B7 UPDATE =B7 VACUUM (Or at least that's what the language reference at http://www.hwaci.com/sw/sqlite/lang.html says.) No GRANT / REVOKE or any other kind of security. It seems to be a plain single user thingie. No ALTER TABLE, SET TRANSACTION etc. Ok, these aren't actually in Entry SQL 92, but everybody else has them... And COPY, PRAGMA, REPLACE, VACUUM, ON CONFLICT etc is not in any SQL standard I know of. It violates SQL92 in a number of ways it seems. For inststance, it's typeless (like GadFly) which means that for instance "00" =3D=3D "0". There are a lot of error checking in SQL that this engine won't do. SQLite ignores checks in CREATE TABLE and has no foreign keys? But it seems a bit closer to SQL than GadFly...and apart from typelessness it seems to support rather extensive SELECT statements. It might be a very useful thing I guess. There are plenty of cases where installing an RDBMS is overkill. >Small memory footprint: less than 20K lines of C code. Erh? Measuring memory footprint in kLoC seems a bit like measuring mass in meters. Although according to the 2.4.0 release notes at freshmeat it seems the binary image needs less than 200kB! Question is how much RAM that actual data requires. If it lifts entire tables into RAM it might be very memory hungry for large databases. >Four times faster than PostgreSQL. Twice as fast as SQLite 1.0. Yea yea, it just depends on what you measure. And how. PostgreSQL is infinitely faster on the features SQLite doesn't support... Benchmarking is a bit too complex to just describe like a scalar like that. >The author, D. Richard Hipp,=20 >is a computer science Ph.D. who knows his stuff. This is not green=20 >software, it is well designed and tested. It was first released in May=20 >2000 and is very actively updated and supported. So, how active is the mailing list? And how good? I saw a subscribe link, but no archive (maybe I just missed it.) --=20 Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From wtrenker@shaw.ca Wed Apr 3 01:37:43 2002 From: wtrenker@shaw.ca (William Trenker) Date: Tue, 02 Apr 2002 17:37:43 -0800 Subject: [DB-SIG] SQLite as a Light DB component for Zope and Python In-Reply-To: <5.1.0.14.0.20020403010746.03520a68@mail.irrblosset.se> References: <5.1.0.14.0.20020401172813.009f3a80@shawmail> Message-ID: <5.1.0.14.0.20020402160408.00a225e0@shawmail> --Boundary_(ID_9kOaZwJ3hhT/q+L3eIFyaA) Content-type: text/plain; x-avg-checked=avg-ok-35745422; charset=iso-8859-1; format=flowed Content-transfer-encoding: quoted-printable At 01:58 AM 4/3/02 +0200, Magnus Lyck=E5 wrote: >So, we expect to see the announcement of a DB-API 2 complient SQLite=20 >driver any day then! :-) I wish ! :-) Actually, I'd love to try it. But maybe there are some=20 DB-API-2 experienced folks out there who could do this in their sleep (if=20 they ever get any time to sleep). The SQLite C API is really that simple=20 -- one data structure pointer representing an open database, 3 functions=20 (open_db,close_db,execute_sql) and 1 callback (to handle the rows in the=20 result set). Of course I'm being a bit silly -- It takes lots of work to put any robust= =20 piece of software together. I'll probably take a stab at it but I wanted=20 to see if the Python/Zope world is even interested. >I'd say a small subset [of SQL92], or perhaps sideset: Yet but probably sufficient for a small, local relational data store. >But it seems a bit closer to SQL than GadFly...and apart from typelessness= =20 >it seems to support rather extensive SELECT statements. It might be a=20 >very useful thing I guess. There are plenty of cases where installing an= =20 >RDBMS is overkill. Yes, that's what I thought; for small amounts of data a large, fully=20 featured RDBMS is overkill. Yet, often, flat tables are not the solution=20 either. Even for small data stores the benefits of the relational model=20 still apply and flat files can be a real pain when the data relationships=20 are complex. For instance, as a simple use-case, consider the frequent, common software= =20 application need for storing configuration data. Often, this data is=20 stored in a collection of flat files. The amount of data in these files=20 may be relatively small but the data relationships can still be very=20 complex. As we all know a collection of flat files doesn't directly=20 provide the mechanism to implement these data relationships. But most RDB= =20 software is far too large to justify using this well established data=20 technology for configuration data. I have often thought it would be=20 beneficial to have a small, low-overhead SQL engine as a software=20 component. I am suggesting SQLite as a candidate. >If it lifts entire tables into RAM it might be very memory hungry for=20 >large databases. This is an excellent and important observation. One of the reasons I'm=20 suggesting SQLite is that it's memory model is, fortunately, more=20 sophisticated than simply lifting entire tables into RAM. To quote from=20 The Architecture Of SQLite (http://www.hwaci.com/sw/sqlite/arch.html): "The B-tree module requests information from the disk in 1024 byte chunks.= =20 The page cache is responsible for reading, writing, and caching these=20 chunks at the behest of the B-tree module. The page cache also provides the= =20 rollback and atomic commit abstraction and takes care of reader/writer=20 locking of the database file. The B- tree driver requests particular pages= =20 from the page cache and notifies the page cache when it wants to modify=20 pages or commit or rollback changes and the page cache handles all the=20 messy details of making sure the requests are handled quickly, safely, and= =20 efficiently." >So, how active is the mailing list? And how good? I saw a subscribe link,= =20 >but no archive (maybe I just missed it.) When you sign up you are taken to a page that lets you have the option of=20 getting to the archives. The SQLite mailing list is a Yahoo eGroup forum=20 so to get at the archives you have to sign up with Yahoo -- oh well. Thanks for commenting, Bill "The commandments of the LORD are right, bringing joy to the heart. The=20 commands of the LORD are clear, giving insight to life . . . For this is=20 the love of God, that we keep His commandments. And His commandments are=20 not burdensome." (Psalm 19:8, 1John=20 5:3) torahteacher.com --Boundary_(ID_9kOaZwJ3hhT/q+L3eIFyaA) Content-type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-35745422 Content-transfer-encoding: 7BIT Content-disposition: inline --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.343 / Virus Database: 190 - Release Date: 3/22/02 --Boundary_(ID_9kOaZwJ3hhT/q+L3eIFyaA)-- From jose@sferacarta.com Wed Apr 3 07:07:33 2002 From: jose@sferacarta.com (jose) Date: Wed, 03 Apr 2002 09:07:33 +0200 Subject: [DB-SIG] SQLite as a Light DB component for Zope and Python References: <5.1.0.14.0.20020401172813.009f3a80@shawmail> Message-ID: <3CAAAA35.3030008@sferacarta.com> I'm working with SQLite right now, I find it a very interesting product, SQLite is tiny, fast, I think it is fast at least as MySQL but SQLite has TRANSACTIONS and it easy to install, for now it needs a python interface based on DB-SIG. IMO SQLite is a good candidate to replace Gadflay Jo William Trenker wrote: > I have noticed on the DB lists lately some concern about the future of > Gadfly. I have been investigating a marvelous little open-source, no > copyright, SQL engine called SQLite: An SQL Database Engine In A C > Library . I am quite > experienced with Python, reasonably experienced with Zope but a > greenhorn at extending Python yet I had a crude but working Python > extension module for SQLite up and running in 2 days (most of that > time figuring out the Python extension conventions). I think Python > needs a lightweight SQL engine as a standard module, and I think this > would be a good Zope product candidate as well. I'm proposing SQLite > as that engine. Here is the developer's feature list, taken from the > link given above: > > Implements a large subset of SQL92. > A complete database (with multiple tables and indices) is stored in a > single disk file. > Atomic commit and rollback protect data integrity. > Small memory footprint: less than 20K lines of C code. > Four times faster than PostgreSQL. Twice as fast as SQLite 1.0. > Very simple C/C++ interface requires the use of only three functions > and one opaque structure. > TCL bindings included. > A TCL-based test suite provides near 100% code coverage. > Self-contained: no external dependencies. > Built and tested under Linux and Win2K. > Sources are uncopyrighted. Use for any purpose. > The SQLite source code is 35% comment. These comments are another > important source of information. > > The author, D. Richard Hipp > , is a computer science Ph.D. who knows his > stuff. This is not green software, it is well designed and tested. > It was first released in May 2000 and is very actively updated and > supported. > > Thanks for listening. > > Bill Trenker > Internet Applications Developer > Kelowna, BC, Canada > > > "The commandments of the LORD are right, bringing joy to the heart. > The commands of the LORD are clear, giving insight to life . . . For > this is the love of God, that we keep His commandments. And His > commandments are not burdensome." (Psalm 19:8, 1John 5:3) > torahteacher.com > > > >------------------------------------------------------------------------ > > >--- >Outgoing mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.343 / Virus Database: 190 - Release Date: 3/22/02 > From jose@sferacarta.com Wed Apr 3 07:16:47 2002 From: jose@sferacarta.com (jose) Date: Wed, 03 Apr 2002 09:16:47 +0200 Subject: [DB-SIG] SQLite as a Light DB component for Zope and Python References: <5.1.0.14.0.20020403010746.03520a68@mail.irrblosset.se> Message-ID: <3CAAAC5F.2050903@sferacarta.com> Magnus Lyckå wrote: > At 17:54 2002-04-01 -0800, William Trenker wrote: > >> but a greenhorn at extending Python yet I had a >> crude but working Python extension module for >> SQLite up and running in 2 days > > > So, we expect to see the announcement of a DB-API 2 > complient SQLite driver any day then! :-) > >> Implements a large subset of SQL92. > > > I'd say a small subset, or perhaps sideset: If you campare it with OCELOT you are right but you have to compare it with Gadflay. > > > SQLite implements the follow syntax: > · BEGIN TRANSACTION (END COMMIT ROLLBACK) > · COPY > · CREATE INDEX > · CREATE TABLE > · CREATE VIEW > · DELETE > · DROP INDEX > · DROP TABLE > · DROP VIEW > · EXPLAIN > · expression > · INSERT > · ON CONFLICT clause > · PRAGMA > · REPLACE > · SELECT > · UPDATE > · VACUUM > (Or at least that's what the language reference at > http://www.hwaci.com/sw/sqlite/lang.html says.) > > No GRANT / REVOKE or any other kind of security. > It seems to be a plain single user thingie. > > No ALTER TABLE, SET TRANSACTION etc. Ok, these aren't > actually in Entry SQL 92, but everybody else has them... > > And COPY, PRAGMA, REPLACE, VACUUM, ON CONFLICT etc is > not in any SQL standard I know of. > > It violates SQL92 in a number of ways it seems. For > inststance, it's typeless (like GadFly) which means that > for instance "00" == "0". There are a lot of error > checking in SQL that this engine won't do. > > SQLite ignores checks in CREATE TABLE and has no foreign > keys? > > But it seems a bit closer to SQL than GadFly...and apart > from typelessness it seems to support rather extensive > SELECT statements. It might be a very useful thing I guess. > There are plenty of cases where installing an RDBMS is > overkill. > >> Small memory footprint: less than 20K lines of C code. > > > Erh? Measuring memory footprint in kLoC seems a bit like > measuring mass in meters. Although according to the 2.4.0 > release notes at freshmeat it seems the binary image needs > less than 200kB! Question is how much RAM that actual data > requires. If it lifts entire tables into RAM it might be > very memory hungry for large databases. > >> Four times faster than PostgreSQL. Twice as fast as SQLite 1.0. > > > Yea yea, it just depends on what you measure. And how. > PostgreSQL is infinitely faster on the features SQLite > doesn't support... Benchmarking is a bit too complex to > just describe like a scalar like that. > >> The author, D. Richard >> Hipp, is a computer science Ph.D. who knows his >> stuff. This is not green software, it is well designed and tested. >> It was first released in May 2000 and is very actively updated and >> supported. > > > So, how active is the mailing list? And how good? I saw > a subscribe link, but no archive (maybe I just missed it.) > > The SQLite mailing list is very active. I am a list member. Jos From ojaeger@psipenta.com Fri Apr 5 13:53:46 2002 From: ojaeger@psipenta.com (ojaeger@psipenta.com) Date: Fri, 5 Apr 2002 15:53:46 +0200 Subject: [DB-SIG] Integer Problems working with Python/mxODBC and MS SQL Server 7 Message-ID: Hello, currently I'm trying to access MSSQL 7 on WinNT from Python 2.1 on an Linux 2.4 (Debian) machine (python 2.1.2/mxODBC 2.0.4/ unixODBC/ FreeTDS 0.53 Driver). Everything works fine, exept that any query of integer values presents strange results. I use the FreeTDS ODBC driver with protocol version 7.0. Here's what happens: >>> import mx.ODBC.unixODBC >>> db = mx.ODBC.unixODBC.DriverConnect("DSN=tralala;UID=hopsasa;PWD=anything") >>> c = db.cursor() >>> c.execute("SELECT id FROM test") >>> res = c.fetchall() >>> res (8,0232304319377730,) >>> The value I expected to receive is 56819 and the datafield in SQL-Server 7 is defined as integer. I tried with TDS protocol version 7.0 and 4.2, but there ware no different results. Every other fieldtype, even text or varchar works correctly. There is no problem when I do the same query with the unixODBC command line query tool 'isql'. All integers are shown correctly. So I think, that the pure ODBC Connection is ok an there must be something between python and mxODBC. BTW, when I query a MySQL database via mxODBC (also via unixODBC) there were no problems with any data type. Any ideas, what can I do? Thanks Olaf From jacobs@penguin.theopalgroup.com Fri Apr 5 13:56:20 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Fri, 5 Apr 2002 08:56:20 -0500 (EST) Subject: [DB-SIG] Integer Problems working with Python/mxODBC and MS SQL Server 7 In-Reply-To: Message-ID: On Fri, 5 Apr 2002 ojaeger@psipenta.com wrote: > currently I'm trying to access MSSQL 7 on WinNT from Python 2.1 on an Linux 2.4 > (Debian) machine (python 2.1.2/mxODBC 2.0.4/ unixODBC/ FreeTDS 0.53 Driver). > Everything works fine, exept that any query of integer values presents strange > results. I use the FreeTDS ODBC driver with protocol version 7.0. > > Any ideas, what can I do? Use Dave Cole's native MSSQL module? Its still fairly rough around the edges, but we've been using it for months without a problem. -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com From mal@lemburg.com Fri Apr 5 14:03:06 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 05 Apr 2002 16:03:06 +0200 Subject: [DB-SIG] Integer Problems working with Python/mxODBC and MS SQL Server 7 References: Message-ID: <3CADAE9A.60B11F5A@lemburg.com> ojaeger@psipenta.com wrote: > > Hello, > > currently I'm trying to access MSSQL 7 on WinNT from Python 2.1 on an Linux 2.4 > (Debian) machine (python 2.1.2/mxODBC 2.0.4/ unixODBC/ FreeTDS 0.53 Driver). > Everything works fine, exept that any query of integer values presents strange > results. I use the FreeTDS ODBC driver with protocol version 7.0. > > Here's what happens: > > >>> import mx.ODBC.unixODBC > >>> db = mx.ODBC.unixODBC.DriverConnect("DSN=tralala;UID=hopsasa;PWD=anything") > >>> c = db.cursor() > >>> c.execute("SELECT id FROM test") > >>> res = c.fetchall() > >>> res > (8,0232304319377730,) > >>> > > The value I expected to receive is 56819 and the datafield in SQL-Server 7 is > defined as integer. Looks like FreeTDS is passing the value as float to mxODBC. To debug the mxODBC-driver connection, you'll have to build a debug version and then run the script with 'python -d'. This will then produce a file mxODBC.log which has all the communication details. Building a debug version is easy: python setup.py mx_autoconf --enable-debugging install > I tried with TDS protocol version 7.0 and 4.2, but there ware no different > results. Every other fieldtype, even text or varchar works correctly. > > There is no problem when I do the same query with the unixODBC command line > query tool 'isql'. All integers are shown correctly. So I think, that the pure > ODBC Connection is ok an there must be something between python and mxODBC. > > BTW, when I query a MySQL database via mxODBC (also via unixODBC) there were no > problems with any data type. > > Any ideas, what can I do? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From broz@mac.com Wed Apr 10 12:56:57 2002 From: broz@mac.com (Richard Brosnahan) Date: Wed, 10 Apr 2002 07:56:57 -0400 Subject: [DB-SIG] DCOracle2 and Exceptions Message-ID: Hi folks, This is probably a simple question, and something I might eventually figure out, but I thought I'd post here to expedite things a bit. I've wrapped a self.oraCursor.execute(theQuery) call in a try block, to trap bad queries. I'd like to know when a bad query gets passed in and what's wrong. Heck, just knowing it's a bad query would be a big help. The problem is, EVERY query passed in drops into one of the exceptions (DatabaseError). I print the query and plunk it into sqlplus, where it works fine. Nothing wrong with it. Indeed, DCOracle is processing the query and the database is modified as expected. What am I missing here? DCOracle2 (stable), Red Hat 7.2, Oracle 9i, Python 2.2. Here's a code snippet: try: try: self.oraCursor = self.conn.cursor() self.oraCursor.execute(theQuery) except(DCOracle2.DatabaseError): print "query error (donno what the problem is) \n" + \ theQuery if self.oraCursor.description: print list(self.oraCursor.description) except(DCOracle2.Error, self.theError): print "generic error: " + self.theError except(DCOracle2.Warning, self.theError): print "query warning: " + self.theError except(DCOracle2.InterfaceError, self.theError): print "interface error: " + self.theError except(DCOracle2.InternalError, self.theError): print "internal error: " + self.theError except(DCOracle2.OperationalError, self.theError): print "OperationalError: " + self.theError except(DCOracle2.ProgrammingError, self.theError): print "ProgrammingError: " + self.theError except(DCOracle2.IntegrityError, self.theError): print "IntegrityError: " + self.theError except(DCOracle2.DataError, self.theError): print "DataError: " + self.theError finally: # print self.oraCursor.fetchall() self.oraCursor.close() Thanks in advance -- Richard Brosnahan Editor in Chief Broz News Hand Picked Technical News Updated Every Business Day! http://broznews.com/ From matt@zope.com Wed Apr 10 15:07:38 2002 From: matt@zope.com (Matthew T. Kromer) Date: Wed, 10 Apr 2002 10:07:38 -0400 Subject: [DB-SIG] DCOracle2 and Exceptions References: Message-ID: <3CB4472A.4090106@zope.com> Richard Brosnahan wrote: >Hi folks, > >This is probably a simple question, and something I might eventually figure >out, but I thought I'd post here to expedite things a bit. > >I've wrapped a self.oraCursor.execute(theQuery) call in a try block, to trap >bad queries. I'd like to know when a bad query gets passed in and what's >wrong. Heck, just knowing it's a bad query would be a big help. The problem >is, EVERY query passed in drops into one of the exceptions (DatabaseError). >I print the query and plunk it into sqlplus, where it works fine. Nothing >wrong with it. Indeed, DCOracle is processing the query and the database is >modified as expected. What am I missing here? > >DCOracle2 (stable), Red Hat 7.2, Oracle 9i, Python 2.2. > >Here's a code snippet: > > > try: > try: > self.oraCursor = self.conn.cursor() > self.oraCursor.execute(theQuery) > >e > And self.conn is a valid connection object? The most likely answer is that you aren't connected to the database. The Oracle error message is raised as the value of the error -- what does it say? -- Matt Kromer Zope Corporation http://www.zope.com/ From broz@mac.com Wed Apr 10 18:05:47 2002 From: broz@mac.com (Richard Brosnahan) Date: Wed, 10 Apr 2002 13:05:47 -0400 Subject: [DB-SIG] DCOracle2 and Exceptions In-Reply-To: <3CB4472A.4090106@zope.com> Message-ID: I've thrown a lot of different query expressions at this, and find most of them work correctly AND it does NOT throw an exception. This is good. Once in awhile I throw a perfectly good query at it, it correctly executes the query and then throws an exception anyway. This is still kind of odd, but very likely something on my end that needs fixing. Thanks very much for your help!! on 4.10.2002 10:07 AM, Matthew T. Kromer at matt@zope.com typed these words: > Richard Brosnahan wrote: > >> Hi folks, >> >> This is probably a simple question, and something I might eventually figure >> out, but I thought I'd post here to expedite things a bit. >> >> I've wrapped a self.oraCursor.execute(theQuery) call in a try block, to trap >> bad queries. I'd like to know when a bad query gets passed in and what's >> wrong. Heck, just knowing it's a bad query would be a big help. The problem >> is, EVERY query passed in drops into one of the exceptions (DatabaseError). >> I print the query and plunk it into sqlplus, where it works fine. Nothing >> wrong with it. Indeed, DCOracle is processing the query and the database is >> modified as expected. What am I missing here? >> >> DCOracle2 (stable), Red Hat 7.2, Oracle 9i, Python 2.2. >> >> Here's a code snippet: >> >> >> try: >> try: >> self.oraCursor = self.conn.cursor() >> self.oraCursor.execute(theQuery) >> >> e >> > > And self.conn is a valid connection object? The most likely answer is > that you aren't connected to the database. The Oracle error message is > raised as the value of the error -- what does it say? -- Richard Brosnahan Editor in Chief Broz News Hand Picked Technical News Updated Every Business Day! http://broznews.com/ From matt@zope.com Wed Apr 10 18:14:23 2002 From: matt@zope.com (Matthew T. Kromer) Date: Wed, 10 Apr 2002 13:14:23 -0400 Subject: [DB-SIG] DCOracle2 and Exceptions References: Message-ID: <3CB472EF.3070307@zope.com> Richard Brosnahan wrote: >I've thrown a lot of different query expressions at this, and find most of >them work correctly AND it does NOT throw an exception. This is good. > >Once in awhile I throw a perfectly good query at it, it correctly executes >the query and then throws an exception anyway. This is still kind of odd, >but very likely something on my end that needs fixing. > >Thanks very much for your help!! > There is code that is fixed in CVS where (prior to the fix) each connection to the database had a SINGLE error handle for all errors to come back in -- this meant that an error caused by a different object on the same connection (a different cursor, a LOB, etc.) could be erroneously picked up due to thread swithing in Python. The CVS version fixes this by making sure that each independant entity that could have a thread switch take place while it is "active" has a separate error handle. -- Matt Kromer Zope Corporation http://www.zope.com/ From cook@pyzine.com Fri Apr 12 20:51:40 2002 From: cook@pyzine.com (Bryan Richard) Date: Fri, 12 Apr 2002 12:51:40 -0700 Subject: [DB-SIG] DB Programming Book Proposal Message-ID: Hi, I'm putting together a proposal for a book on beginning database programming with Python. Two questions: (1) Do you think there is an audience for this material? (2) What you like to see covered that would spark your interest or what are the base topics that *must* be covered. Thanks in advance for any feedback. Be well, Bryan "cook" Richard cook@pyzine.com Editor, Py || Py || Independent Print Zine for Python Developers || www.PyZine.com || || Py Volume 01 Issue 01 - Out Now! || The Inaugural Manifestation for the Sodality of the Snake. || $3.00 US & $5.00 International From fog@initd.org Sat Apr 13 00:05:58 2002 From: fog@initd.org (Federico Di Gregorio) Date: 13 Apr 2002 01:05:58 +0200 Subject: [DB-SIG] DB Programming Book Proposal In-Reply-To: References: Message-ID: <1018652759.4835.190.camel@nenya> --=-WrjIBhxPxQH+JlF703Ur Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il ven, 2002-04-12 alle 21:51, Bryan Richard ha scritto: > Hi,=20 > =20 > I'm putting together a proposal for a book on beginning database programm= ing with Python.=20 > =20 > Two questions:=20 > (1) Do you think there is an audience for this material?=20 > (2) What you like to see covered that would spark your interest or what a= re the base topics that *must* be covered.=20 i started writing a book i titled "Accessing Databases Using the Python DBAPI-2.0" some time ago and i am slowly adding material to it when i have the time. it is very far from being complete, but if anyone is interested, my work in progress is available at: http://initd.org/pub/software/psycopg/ under the name dbapi20programming-0.0.20020413.tar.gz. (the version may change, it is based on the timestamp of when i build the tar). a more formal annouce will be sent to the usual places when i finish it, in a couple of months if all goes well (but maybe 3 or 4). --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org All programmers are optimists. -- Frederick P. Brooks, Jr. --=-WrjIBhxPxQH+JlF703Ur Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Per informazioni si veda http://www.gnupg.org iEYEABECAAYFAjy3aFYACgkQvcCgrgZGjevdigCeKtDxG08hE/gMv6ZyGvJ06ENO qaEAnAhoGsCl6H4m1N8O4uCZbopY5X6i =ghk2 -----END PGP SIGNATURE----- --=-WrjIBhxPxQH+JlF703Ur-- From magnus@thinkware.se Sun Apr 14 14:36:01 2002 From: magnus@thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Sun, 14 Apr 2002 15:36:01 +0200 Subject: [DB-SIG] SQL Relay Message-ID: <5.1.0.14.0.20020414125125.00b99230@mail.irrblosset.se> I just stumbled over SQL Relay and I was a bit surprised that I never heard of that before. It seems to have support both for python with a custom API and with a DB-API compliant driver. Does anyone have experience of this? Shouldn't it be mentioned at http://www.python.org/topics/database/modules.html ? /Magnus --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From dieter@handshake.de Sun Apr 14 22:18:06 2002 From: dieter@handshake.de (Dieter Maurer) Date: Sun, 14 Apr 2002 23:18:06 +0200 Subject: [DB-SIG] SQL Relay In-Reply-To: <5.1.0.14.0.20020414125125.00b99230@mail.irrblosset.se> References: <5.1.0.14.0.20020414125125.00b99230@mail.irrblosset.se> Message-ID: <15545.61966.517059.918018@linux.local> Magnus =?iso-8859-1?Q?Lyck=E5?= writes: > I just stumbled over SQL Relay and > I was a bit surprised that I never heard of that before. It seems to have > support both for python with a custom API and with a DB-API compliant > driver. > > Does anyone have experience of this? I have. You can find several messages by Googling "lists.zope.org" for "SQLRelay". David plan to make a new release soon that addresses some of the weak points reported in the above messages. Andreas Tille (among others) works on a debian package for SQLRelay addressing more weak points. Dieter From mal@lemburg.com Mon Apr 15 12:06:46 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 15 Apr 2002 13:06:46 +0200 Subject: [DB-SIG] DB Programming Book Proposal References: Message-ID: <3CBAB446.22B8BD44@lemburg.com> Bryan Richard wrote: > > Hi, > > I'm putting together a proposal for a book on beginning database programming with Python. > > Two questions: > (1) Do you think there is an audience for this material? Yes. > (2) What you like to see covered that would spark your interest or what are the base topics that *must* be covered. > * various ways to access databases (depending on client and server platforms) and their differences * comparisons of implemented DB API extensions and data types * explain typical gotchas like dealing with Unicode data, handling unknown data types (e.g. user types), problems during connect and ways to work around them (all of these are usually DB API and database specific), decimal vs. Python floats etc. > Thanks in advance for any feedback. > > Be well, > > Bryan "cook" Richard cook@pyzine.com > Editor, Py > > || Py > || Independent Print Zine for Python Developers > || www.PyZine.com > || > || Py Volume 01 Issue 01 - Out Now! > || The Inaugural Manifestation for the Sodality of the Snake. > || $3.00 US & $5.00 International When can we expect shipment of Py 01 (to Germany) ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From cook@pyzine.com Tue Apr 16 17:34:40 2002 From: cook@pyzine.com (Bryan Richard) Date: Tue, 16 Apr 2002 09:34:40 -0700 Subject: [DB-SIG] DB Programming Book Proposal Message-ID: [Marc wrote] >* various ways to access databases (depending on client and server platforms) and their differences Marc, thanks for the feedback. This is the approach I have been considering: win32com + ADO on MS w/SQL Server, zxJDBC + Jython on *nix w/mySQL, etc. Sort of a cookbook style focusing on databases. But if the response to this email is any indication of the level of interest for a publication on this topic, perhaps I should shelf this idea and consider another. Be well, Bryan "cook" Richard cook@pyzine.com Editor, Py || Py || Independent Print Zine for Python Developers || www.PyZine.com || || Py Volume 01 Issue 01 - Out Now! || The Inaugural Manifestation for the Sodality of the Snake. || $3.00 US & $5.00 International -----Original Message----- Bryan Richard wrote: > > Hi, > > I'm putting together a proposal for a book on beginning database programming with Python. > > Two questions: > (1) Do you think there is an audience for this material? Yes. > (2) What you like to see covered that would spark your interest or what are the base topics that *must* be covered. > * various ways to access databases (depending on client and server platforms) and their differences * comparisons of implemented DB API extensions and data types * explain typical gotchas like dealing with Unicode data, handling unknown data types (e.g. user types), problems during connect and ways to work around them (all of these are usually DB API and database specific), decimal vs. Python floats etc. > Thanks in advance for any feedback. > > Be well, > > Bryan "cook" Richard cook@pyzine.com > Editor, Py > > || Py > || Independent Print Zine for Python Developers > || www.PyZine.com > || > || Py Volume 01 Issue 01 - Out Now! > || The Inaugural Manifestation for the Sodality of the Snake. > || $3.00 US & $5.00 International When can we expect shipment of Py 01 (to Germany) ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Tue Apr 16 18:11:42 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 16 Apr 2002 19:11:42 +0200 Subject: [DB-SIG] DB Programming Book Proposal References: Message-ID: <3CBC5B4E.BAB20AAC@lemburg.com> Bryan Richard wrote: > > [Marc wrote] > >* various ways to access databases (depending on client and server platforms) and their differences > > Marc, thanks for the feedback. > > This is the approach I have been considering: win32com + ADO on MS w/SQL Server, zxJDBC + Jython on *nix w/mySQL, etc. Sort of a cookbook style focusing on databases. > Sounds like a plan, but you need lots of experience with database to fill the spaces with content, since each setup has its own little quirks and things also change when moving from single tier to multiple tier setups. > But if the response to this email is any indication of the level of interest for a publication on this topic, perhaps I should shelf this idea and consider another. > You should probably be asking on c.l.p and maybe write a fe articles in Py to see how well this area of interest is accepted. Note that Programming Python on Win32 already includes quite a bit of information in this area. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Anthony Baxter Wed Apr 17 05:17:01 2002 From: Anthony Baxter (Anthony Baxter) Date: Wed, 17 Apr 2002 14:17:01 +1000 Subject: [DB-SIG] DB Programming Book Proposal In-Reply-To: Message from "M.-A. Lemburg" of "Mon, 15 Apr 2002 13:06:46 +0200." <3CBAB446.22B8BD44@lemburg.com> Message-ID: <200204170417.g3H4H1520575@localhost.localdomain> In addition, it might be worth covering some of the various ways of going from tuple results of your typical fetch() operation to a smarter type of object. -- Anthony Baxter It's never too late to have a happy childhood. From djc@object-craft.com.au Sun Apr 21 15:49:20 2002 From: djc@object-craft.com.au (Dave Cole) Date: 22 Apr 2002 00:49:20 +1000 Subject: [DB-SIG] Sybase module 0.35pre1 released In-Reply-To: References: 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. Notes: In this release the module uses callback instead of inline error handling from the Sybase CT library. This has caused quite extensive changes to the threading support inside the low level extension module. One of the nice side effects of using callback error handling is that server errors while executing stored procedures will now be reported correctly. FreeTDS support is much improved in this version. You will still experience segfaults while using FreeTDS though. These issues are still being worked on. For the adventurous, you can build for FreeTDS like this: python setup.py build_ext -D HAVE_FREETDS -U WANT_BULKCOPY python setup.py install The module is available here: http://www.object-craft.com.au/projects/sybase/sybase-0.35pre1.tar.gz The module home page is here: http://www.object-craft.com.au/projects/sybase/ - Dave -- http://www.object-craft.com.au From ogd116@mail.usask.ca Sun Apr 21 18:35:51 2002 From: ogd116@mail.usask.ca (Ognen Duzlevski) Date: Sun, 21 Apr 2002 11:35:51 -0600 Subject: [DB-SIG] problem with MySQLdb Message-ID: <001a01c1e95a$fb9e5270$ee1de980@usask.ca> This is a multi-part message in MIME format. --Boundary_(ID_r2XHdnWtbrRHFeNi2iM8Dg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hello, I have the following simple cgi script: #!c:/Python22/python.exe import cgitb, cgi, MySQLdb cgitb.enable() print "Content-Type: text/html" print print "CGI script output" print "

This is my first CGI script

" print "Hello, world!" dbs = MySQLdb.connect(db='test',host='localhost',user='ognen',passwd='blahblah') c = db.cursor() c.execute("SELECT * FROM ") s = c.fetchone() print s The whole thing works from the command prompt (python test.py) if I remove host='localhost' part from connect() but with it it wont work. When I try to access the script through the web browser I get the correct result up to the point where MySQL.connect(...) is executed: Operational error: 2003, "Can't connect to MySQL server on 'localhost' (10061)") __doc__ = 'Exception raised for errors that are related to ...cation\n error occurred during processing, etc.' __getitem__ = > __init__ = > __module__ = '_mysql_exceptions' __str__ = > args = (2003, "Can't connect to MySQL server on 'localhost' (10061)") The script accessed through the web will not work with any combination of host, user and db parameters I have tried. The user has all privileges GRANTed properly as far as I can tell on the test database. If I do c:\mysql\bin\mysql -u ognen test it works just fine. Any help would be appreciated. Ognen --Boundary_(ID_r2XHdnWtbrRHFeNi2iM8Dg) Content-type: text/html; charset=iso-8859-1
Hello,
 
I have the following simple cgi script:
 
#!c:/Python22/python.exe
import cgitb, cgi, MySQLdb
cgitb.enable()
 
print "Content-Type: text/html"
print
print "<TITLE>CGI script output</TITLE>"
print "<H1>This is my first CGI script</H1>"
print "Hello, world!"
 
dbs = MySQLdb.connect(db='test',host='localhost',user='ognen',passwd='blahblah')
c = db.cursor()
c.execute("SELECT * FROM ")
s = c.fetchone()
print s
 
The whole thing works from the command prompt (python test.py) if I remove host='localhost' part from connect() but with it it wont work. When I try to access the script through the web browser I get the correct result up to the point where MySQL.connect(...) is executed:
 
Operational error: 2003, "Can't connect to MySQL server on 'localhost' (10061)")
      __doc__ = 'Exception raised for errors that are related to ...cation\n error occurred during processing, etc.'
      __getitem__ = <bound method OperationalError.__getitem__ of <_...eptions.OperationalError instance at 0x00840040>>
      __init__ = <bound method OperationalError.__init__ of <_mys...eptions.OperationalError instance at 0x00840040>>
      __module__ = '_mysql_exceptions'
      __str__ = <bound method OperationalError.__str__ of <_mysq...eptions.OperationalError instance at 0x00840040>>
      args = (2003, "Can't connect to MySQL server on 'localhost' (10061)")
 
The script accessed through the web will not work with any combination of host, user and db parameters I have tried. The user has all privileges GRANTed properly as far as I can tell on the test database. If I do c:\mysql\bin\mysql -u ognen test it works just fine.
 
Any help would be appreciated.
 
Ognen
--Boundary_(ID_r2XHdnWtbrRHFeNi2iM8Dg)-- From bzimmer@ziclix.com Mon Apr 22 21:02:19 2002 From: bzimmer@ziclix.com (brian zimmer) Date: Mon, 22 Apr 2002 15:02:19 -0500 Subject: [DB-SIG] return value of .fetchall() with an empty result set Message-ID: <443848701980194E9A471774F367637A090AD3@LIILMTST03.mailtask.com> I need a clarification on the use of .fetchall(). Which of the below scenarios is correct? The call c.execute("select * from some_table where 1=0") data = c.fetchall() (1) raises an Error (2) data == [] (3) data is None Under some cases I can not know the number of rows returned in the query so the user must try one of the fetchXXX methods. I currently implement zxJDBC as (3) which is probably the most incorrect. I *think* it should probably return (2) to be more consistent with .fetchmany(). (1) seems rather harsh to me as this is not really an exceptional case, there's just no data. Either way it appears I'm not consistent with the API. How have others implemented this? Is everyone else raising an Error? Is the preferred method to check the .rowcount attribute and only call .fetchXXX if it's greater than zero? thanks, brian From andy47@halfcooked.com Tue Apr 23 00:21:24 2002 From: andy47@halfcooked.com (Andy Todd) Date: Tue, 23 Apr 2002 09:21:24 +1000 Subject: [DB-SIG] return value of .fetchall() with an empty result set References: <443848701980194E9A471774F367637A090AD3@LIILMTST03.mailtask.com> Message-ID: <3CC49AF4.5050403@halfcooked.com> brian zimmer wrote: > I need a clarification on the use of .fetchall(). Which of the below > scenarios is correct? > > The call > > c.execute("select * from some_table where 1=0") > data = c.fetchall() > > (1) raises an Error > (2) data == [] > (3) data is None > > Under some cases I can not know the number of rows returned in the query > so the user must try one of the fetchXXX methods. I currently implement > zxJDBC as (3) which is probably the most incorrect. I *think* it should > probably return (2) to be more consistent with .fetchmany(). (1) seems > rather harsh to me as this is not really an exceptional case, there's > just no data. Either way it appears I'm not consistent with the API. > How have others implemented this? Is everyone else raising an Error? > Is the preferred method to check the .rowcount attribute and only call > .fetchXXX if it's greater than zero? > > thanks, > > brian > > Brian, All of the db modules I use return data==() ( or data==[] ) when fetchall returns no rows. This is consistent both with Python and SQL because your query is valid but returns an empty set. I wouldn't expect a cursor method to raise an exception unless some part of the database operation is incorrect or fails and I wouldn't expect a valid call to return None, but that would be better than raising an exception. The DB-API (http://www.python.org/topics/database/DatabaseAPI-2.0.html) is not entirely clear on this subject, so maybe some clarification is required. I would suggest that when writing your own database handler that the most important thing is to be consistent in how you return the empty set from fetchone, fetchmany and fetchall. HTH, Andy -- ---------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com From bzimmer@ziclix.com Mon Apr 22 12:41:53 2002 From: bzimmer@ziclix.com (brian zimmer) Date: Mon, 22 Apr 2002 06:41:53 -0500 Subject: [DB-SIG] return value of .fetchall() with an empty result set In-Reply-To: <3CC49AF4.5050403@halfcooked.com> Message-ID: <001101c1e9f2$b6573310$7401a8c0@mountain> > > Brian, > > All of the db modules I use return data==() ( or data==[] ) when > fetchall returns no rows. > zxJDBC does now as well ;) > This is consistent both with Python and SQL because your > query is valid > but returns an empty set. I wouldn't expect a cursor method > to raise an > exception unless some part of the database operation is incorrect or > fails and I wouldn't expect a valid call to return None, but > that would > be better than raising an exception. > > The DB-API > (http://www.python.org/topics/database/Databas> eAPI-2.0.html) > > is not entirely clear on this subject, so > maybe some clarification is > required. I would suggest that when writing your own database handler I think it should be spelled out as it is for the other two .fetchXXX() methods. > that the most important thing is to be consistent in how you > return the > empty set from fetchone, fetchmany and fetchall. > It is now. I'm suprised it went this long with no one having said anything. I'm more suprised that I was so inconsistent. thanks, brian From mal@lemburg.com Thu Apr 25 13:22:54 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 25 Apr 2002 14:22:54 +0200 Subject: [DB-SIG] return value of .fetchall() with an empty result set References: <443848701980194E9A471774F367637A090AD3@LIILMTST03.mailtask.com> Message-ID: <3CC7F51E.30941D1D@lemburg.com> brian zimmer wrote: > > I need a clarification on the use of .fetchall(). Which of the below > scenarios is correct? > > The call > > c.execute("select * from some_table where 1=0") > data = c.fetchall() > > (1) raises an Error > (2) data == [] This one. > (3) data is None > > Under some cases I can not know the number of rows returned in the query > so the user must try one of the fetchXXX methods. I currently implement > zxJDBC as (3) which is probably the most incorrect. I *think* it should > probably return (2) to be more consistent with .fetchmany(). (1) seems > rather harsh to me as this is not really an exceptional case, there's > just no data. Either way it appears I'm not consistent with the API. > How have others implemented this? No. > Is everyone else raising an Error? No. > Is the preferred method to check the .rowcount attribute and only call > .fetchXXX if it's greater than zero? No. .fetchall() should return an empty list which nicely maps to an empty result set. HTH, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/