From carsten at uniqsys.com Sat Dec 2 05:22:50 2006 From: carsten at uniqsys.com (Carsten Haese) Date: Fri, 01 Dec 2006 23:22:50 -0500 Subject: [DB-SIG] [ANN] InformixDB-2.4 released Message-ID: <1165033370.3304.3.camel@localhost.localdomain> I am pleased to announce a new release of InformixDB, the DB-API 2.0 module for connecting to IBM Informix database engines. The list of changes since version 2.3 is short but sweet: - Implement 'named' parameter style to optionally bind query parameters by name - Implement option to retrieve opaque types in their binary representation Downloads and info at http://informixdb.sourceforge.net Best regards, Carsten Haese From phd at phd.pp.ru Mon Dec 4 18:58:19 2006 From: phd at phd.pp.ru (Oleg Broytmann) Date: Mon, 4 Dec 2006 20:58:19 +0300 Subject: [DB-SIG] SQLObject release 0.7.2 Message-ID: <20061204175819.GB32211@phd.pp.ru> Hello! I'm pleased to announce the 0.7.2 release of SQLObject. What is SQLObject ================= SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, and Firebird. It also has newly added support for Sybase, MSSQL and MaxDB (also known as SAPDB). Where is SQLObject ================== Site: http://sqlobject.org Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: http://cheeseshop.python.org/pypi/SQLObject/0.7.2 News and changes: http://sqlobject.org/docs/News.html What's New ========== Features & Interface -------------------- * sqlbuilder.Select now supports JOINs exactly like SQLObject.select. * destroySelf() removes the object from related joins. Bug Fixes --------- * Fixed a number of unicode-related problems with newer MySQLdb. * If the DB API driver returns timedelta instead of time (MySQLdb does this) it is converted to time; but if the timedelta has days an exception is raised. * Fixed a number of bugs in InheritableSQLObject related to foreign keys. * Fixed a bug in InheritableSQLObject related to the order of tableRegistry dictionary. * A bug fix that allows to use SQLObject with DateTime from Zope. Documentation Added ------------------- * Added "How can I define my own intermediate table in my Many-to-Many relationship?" to FAQ. For a more complete list, please see the news: http://sqlobject.org/docs/News.html Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From haraldarminmassa at gmail.com Thu Dec 7 19:32:19 2006 From: haraldarminmassa at gmail.com (Harald Armin Massa) Date: Thu, 7 Dec 2006 19:32:19 +0100 Subject: [DB-SIG] cx_Oracle: RuntimeError: Unable to acquire Oracle environment handle Message-ID: <7be3f35d0612071032r43b9a138re529c34d5349450b@mail.gmail.com> Hello, I am using cx_Oracle for quite some time. On more then 120 computers everything works out fine. My usage is on Windows XP / Windows 2003. The applications are bundled with py2exe. NOW there is ONE stubborn computer, which torments me with the error message: RuntimeError: Unable to acquire Oracle environment handle This error message appears when the py2exe bundled program trys to connect to oracle via cx_Oracle.connect The challenging part: on the same computer, when running the same program from source via python scriptname.py, all works out fine. Of course I googled this error, and found the various challenges with ORACLE_HOME ... and ORACLE_HOME *is* set to c:\oracle\ora92; within c:\oracle\ora92\bin there *is* an OCI.DLL, and windows path contains C:\oracle\ora92\bin; But still... on py2exed application, the error results, on non-py2exed, it works. Who can give me a push to check something in addition? Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Reinsburgstra?e 202b 70197 Stuttgart 0173/9409607 - Python: the only language with more web frameworks than keywords. From sable.sungard at gmail.com Tue Dec 12 16:25:47 2006 From: sable.sungard at gmail.com (=?ISO-8859-1?Q?S=E9bastien_Sabl=E9?=) Date: Tue, 12 Dec 2006 16:25:47 +0100 Subject: [DB-SIG] Sybase module 0.38pre1 released 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. MAJOR CHANGES SINCE 0.37: * This release works with python 2.5 * It also works with sybase 15 * It works with 64bits clients * It can be configured to return native python datetime objects * The bug "This routine cannot be called because another command structure has results pending." which appears in various cases has been corrected * It includes a unitary test suite based on the dbapi2.0 compliance test suite From sable.sungard at gmail.com Wed Dec 13 11:12:53 2006 From: sable.sungard at gmail.com (=?ISO-8859-1?Q?S=E9bastien_Sabl=E9?=) Date: Wed, 13 Dec 2006 11:12:53 +0100 Subject: [DB-SIG] Sybase module 0.38pre1 released In-Reply-To: References: Message-ID: By the way, I forgot to say that new releases can now be downloaded from this page: https://sourceforge.net/project/showfiles.php?group_id=184050 regards -- S?bastien Sabl? 2006/12/12, S?bastien Sabl? : > 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. > > MAJOR CHANGES SINCE 0.37: > > * This release works with python 2.5 > > * It also works with sybase 15 > > * It works with 64bits clients > > * It can be configured to return native python datetime objects > > * The bug "This routine cannot be called because another command > structure has results pending." which appears in various cases has > been corrected > > * It includes a unitary test suite based on the dbapi2.0 compliance > test suite > From phd at phd.pp.ru Mon Dec 18 20:15:31 2006 From: phd at phd.pp.ru (Oleg Broytmann) Date: Mon, 18 Dec 2006 22:15:31 +0300 Subject: [DB-SIG] SQLObject 0.8.0b1 Message-ID: <20061218191531.GC8065@phd.pp.ru> Hello! I'm pleased to announce the 0.8.0b1 release of SQLObject. This is the first beta of the new branch. Taking into account that it is a result of rather large job the beta period will be prolonged. Meanwhile the stable 0.7 branch will be maintained, and there will be at least 0.7.3 release. What is SQLObject ================= SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, and Firebird. It also has newly added support for Sybase, MSSQL and MaxDB (also known as SAPDB). Where is SQLObject ================== Site: http://sqlobject.org Development: http://sqlobject.org/devel/ Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: http://cheeseshop.python.org/pypi/SQLObject/0.8.0b1 News and changes: http://sqlobject.org/devel/News.html What's New ========== Features & Interface -------------------- * It is now possible to create tables that reference each other. Constraints (in the DBMSes that support constraints) are added after the tables have been created. * Added ``createSQL`` as an option for sqlmeta. Here you can add related SQL you want executed by sqlobject-admin create after table creation. createSQL expects a string, list, or dictionary. If using a dictionary the key should be a dbName value (ex. 'postgres') and the value should be a string or list. Examples in sqlobject/tests/test_sqlobject_admin.py or at * Added method ``sqlhub.doInTransaction(callable, *args, **kwargs)``, to be used like:: sqlhub.doInTransaction(process_request, os.environ) This will run ``process_request(os.environ)``. The return value will be preserved. * Added method ``.getOne([default])`` to ``SelectResults`` (these are the objects returned by ``.select()`` and ``.selectBy()``). This returns a single object, when the query is expected to return only one object. The single argument is the value to return when zero results are found (more than one result is always an error). If no default is given, it is an error if no such object exists. * Added a WSGI middleware (in ``sqlobject.wsgi_middleware``) for configuring the database for the request. Also handles transactions. Available as ``egg:SQLObject`` in Paste Deploy configuration files. * New joins! ManyToMany and OneToMany; not fully documented yet, but still more sensible and smarter. * SELECT FOR UPDATE * New module dberrors.py - a hierarchy of exceptions. Translation of DB API module's exceptions to the new hierarchy is performed for SQLite and MySQL. * SQLiteConnection got a new keyword "factory" - a name or a reference to a factory function that returns a connection class; useful for implementing functions or aggregates. See test_select.py and test_sqlite_factory.py for examples. * SQLObject now disallows columns with names that collide with existing variables and methods, such as "_init", "expire", "set" and so on. Small Features -------------- * Configurable client character set (encoding) for MySQL. * Added a close option to .commit(), so you can close the transaction as you commit it. * DecimalValidator. * Added .expireAll() methods to sqlmeta and connection objects, to expire all instances in those cases. * String IDs. * FOREIGN KEY for MySQL. * Support for sqlite3 (a builtin module in Python 2.5). * SelectResults cannot be queried for truth value; in any case it was meaningless - the result was always True; now __nonzero__() raises NotImplementedError in case one tries bool(MyTable.select()) or "if MyTable.select():..." Bug Fixes --------- * Fixed problem with sqlite and threads; connections are no longer shared between threads for sqlite (except for :memory:). * The reference loop between SQLObject and SQLObjectState eliminated using weak references. For a more complete list, please see the news: http://sqlobject.org/devel/News.html Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From aprotin at research.att.com Mon Dec 18 22:56:28 2006 From: aprotin at research.att.com (Art Protin) Date: Mon, 18 Dec 2006 16:56:28 -0500 Subject: [DB-SIG] Clarification of cursor.arraysize Message-ID: <45870E8C.4000404@research.att.com> Dear folks, I find yet again that I am confused by what I read in pep-0249. This time it is the last line describing the attribute of cursor objects named .arraysize (I quote here both paragraphs): This read/write attribute specifies the number of rows to fetch at a time with fetchmany(). It defaults to 1 meaning to fetch a single row at a time. Implementations must observe this value with respect to the fetchmany() method, but are free to interact with the database a single row at a time. It may also be used in the implementation of executemany(). I fail to grasp how .arraysize could have any bearing on .executemany() or for that matter any operation other than fetchmany(). Thus I find I must request aid in understanding what the intent is here - HELP, please. While I am bothering you good people with my silly questions, I might just as well tack on another: if one invokes .executemany with a seq_of_parameters that is empty (like a_cursor.executemany(SQL, []) ) shouldn't the interface module execute the query zero times, ie, not execute the query at all? I think that is what I am going to do but I would like to hear your comments either way. Thank you all, Arthur Protin From mal at egenix.com Tue Dec 19 01:01:35 2006 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 19 Dec 2006 01:01:35 +0100 Subject: [DB-SIG] Clarification of cursor.arraysize In-Reply-To: <45870E8C.4000404@research.att.com> References: <45870E8C.4000404@research.att.com> Message-ID: <45872BDF.8020801@egenix.com> On 2006-12-18 22:56, Art Protin wrote: > Dear folks, > I find yet again that I am confused by what I read in pep-0249. > This time it is the last line describing the attribute of cursor objects > named .arraysize (I quote here both paragraphs): > > This read/write attribute specifies the number of rows to > fetch at a time with fetchmany(). It defaults to 1 meaning > to fetch a single row at a time. > > Implementations must observe this value with respect to > the fetchmany() method, but are free to interact with the > database a single row at a time. It may also be used in > the implementation of executemany(). > > I fail to grasp how .arraysize could have any bearing on .executemany() > or for that matter any operation other than fetchmany(). Thus I find I > must request aid in understanding what the intent is here - HELP, please. It's actually very simple: .arraysize specifies the default for the parameter to .fetchmany(). > While I am bothering you good people with my silly questions, I > might just as well tack on another: if one invokes .executemany with a > seq_of_parameters that is empty (like > > a_cursor.executemany(SQL, []) > > ) shouldn't the interface module execute the query zero times, ie, not > execute the query at all? The SQL command could be a command that doesn't have any parameters. In such a case, the above would be the same as .execute(SQL). I agree that this is a somewhat constructed case, but it can occur in situations where you write generic code for e.g. database abstraction layers. > I think that is what I am going to do but I would like to hear your > comments either way. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2006) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From carsten at uniqsys.com Tue Dec 19 01:26:46 2006 From: carsten at uniqsys.com (Carsten Haese) Date: Mon, 18 Dec 2006 19:26:46 -0500 Subject: [DB-SIG] Clarification of cursor.arraysize In-Reply-To: <45870E8C.4000404@research.att.com> References: <45870E8C.4000404@research.att.com> Message-ID: <1166488006.3297.3.camel@localhost.localdomain> On Mon, 2006-12-18 at 16:56 -0500, Art Protin wrote: > Dear folks, > I find yet again that I am confused by what I read in pep-0249. > This time it is the last line describing the attribute of cursor objects > named .arraysize (I quote here both paragraphs): > > This read/write attribute specifies the number of rows to > fetch at a time with fetchmany(). It defaults to 1 meaning > to fetch a single row at a time. > > Implementations must observe this value with respect to > the fetchmany() method, but are free to interact with the > database a single row at a time. It may also be used in > the implementation of executemany(). > > I fail to grasp how .arraysize could have any bearing on .executemany() > or for that matter any operation other than fetchmany(). Thus I find I > must request aid in understanding what the intent is here - HELP, please. It says "It *may* be used in the implementation of executemany()." I imagine this would be useful for a database API that allows passing parameters in bulk. You're free to implement executemany() without referring to arraysize if there is no advantage in referring to arraysize. > While I am bothering you good people with my silly questions, I > might just as well tack on another: if one invokes .executemany with a > seq_of_parameters that is empty (like > > a_cursor.executemany(SQL, []) > > ) shouldn't the interface module execute the query zero times, ie, not > execute the query at all? Yes, executemany() with an empty sequence is a no-op. -- Carsten Haese | Phone: (419) 861-3331 Software Engineer | Direct Line: (419) 794-2531 Unique Systems, Inc. | FAX: (419) 893-2840 1687 Woodlands Drive | Cell: (419) 343-7045 Maumee, OH 43537 | Email: carsten at uniqsys.com From carsten at uniqsys.com Tue Dec 19 01:34:43 2006 From: carsten at uniqsys.com (Carsten Haese) Date: Mon, 18 Dec 2006 19:34:43 -0500 Subject: [DB-SIG] Clarification of cursor.arraysize In-Reply-To: <45872BDF.8020801@egenix.com> References: <45870E8C.4000404@research.att.com> <45872BDF.8020801@egenix.com> Message-ID: <1166488483.3297.10.camel@localhost.localdomain> On Tue, 2006-12-19 at 01:01 +0100, M.-A. Lemburg wrote: > On 2006-12-18 22:56, Art Protin wrote: > > While I am bothering you good people with my silly questions, I > > might just as well tack on another: if one invokes .executemany with a > > seq_of_parameters that is empty (like > > > > a_cursor.executemany(SQL, []) > > > > ) shouldn't the interface module execute the query zero times, ie, not > > execute the query at all? > > The SQL command could be a command that doesn't have any parameters. > In such a case, the above would be the same as .execute(SQL). I beg to differ. I think it's quite clear from the spec that cursor.executemany(SQL, []) is a no-op. To actually execute a parameter-less query with executemany, you'd have to pass an empty parameter tuple as in cursor.executemany(SQL, [()]). -- Carsten Haese | Phone: (419) 861-3331 Software Engineer | Direct Line: (419) 794-2531 Unique Systems, Inc. | FAX: (419) 893-2840 1687 Woodlands Drive | Cell: (419) 343-7045 Maumee, OH 43537 | Email: carsten at uniqsys.com From mal at egenix.com Tue Dec 19 09:43:00 2006 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 19 Dec 2006 09:43:00 +0100 Subject: [DB-SIG] Clarification of cursor.arraysize In-Reply-To: <1166488483.3297.10.camel@localhost.localdomain> References: <45870E8C.4000404@research.att.com> <45872BDF.8020801@egenix.com> <1166488483.3297.10.camel@localhost.localdomain> Message-ID: <4587A614.5000600@egenix.com> On 2006-12-19 01:34, Carsten Haese wrote: > On Tue, 2006-12-19 at 01:01 +0100, M.-A. Lemburg wrote: >> On 2006-12-18 22:56, Art Protin wrote: > >>> While I am bothering you good people with my silly questions, I >>> might just as well tack on another: if one invokes .executemany with a >>> seq_of_parameters that is empty (like >>> >>> a_cursor.executemany(SQL, []) >>> >>> ) shouldn't the interface module execute the query zero times, ie, not >>> execute the query at all? >> The SQL command could be a command that doesn't have any parameters. >> In such a case, the above would be the same as .execute(SQL). > > I beg to differ. I think it's quite clear from the spec that > cursor.executemany(SQL, []) is a no-op. To actually execute a > parameter-less query with executemany, you'd have to pass an empty > parameter tuple as in cursor.executemany(SQL, [()]). You're right. Shouldn't be posting replies that late at night :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2006) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From aprotin at research.att.com Tue Dec 19 16:28:18 2006 From: aprotin at research.att.com (Art Protin) Date: Tue, 19 Dec 2006 10:28:18 -0500 Subject: [DB-SIG] Clarification of cursor.arraysize In-Reply-To: <1166488006.3297.3.camel@localhost.localdomain> References: <45870E8C.4000404@research.att.com> <1166488006.3297.3.camel@localhost.localdomain> Message-ID: <45880512.3030602@research.att.com> Dear folks, Carsten Haese wrote: >On Mon, 2006-12-18 at 16:56 -0500, Art Protin wrote: > > >>Dear folks, >> I find yet again that I am confused by what I read in pep-0249. >>This time it is the last line describing the attribute of cursor objects >>named .arraysize (I quote here both paragraphs): >> >> This read/write attribute specifies the number of rows to >> fetch at a time with fetchmany(). It defaults to 1 meaning >> to fetch a single row at a time. >> >> Implementations must observe this value with respect to >> the fetchmany() method, but are free to interact with the >> database a single row at a time. It may also be used in >> the implementation of executemany(). >> >>I fail to grasp how .arraysize could have any bearing on .executemany() >>or for that matter any operation other than fetchmany(). Thus I find I >>must request aid in understanding what the intent is here - HELP, please. >> >> > >It says "It *may* be used in the implementation of executemany()." I >imagine this would be useful for a database API that allows passing >parameters in bulk. You're free to implement executemany() without >referring to arraysize if there is no advantage in referring to >arraysize. > > > I am probably being dense here, but ... This seems to be like saying "The implementor is free to transfer parameters for .executemany() in groups of 17, or not." Why mention it at all? Did someone write an interface that did tie the value for the number of rows to transfer to the value for the number of sets of parameters to transfer? I suspect that some piece of the historical debate in developing this specification may have been lost here. I think that either the specification should omit that last line or include enough additional information to permit the reader to see not only how they can be linked (actually that IS simple enough to be left out) but a reason why an implementation might benefit from having them linked (which I still have not heard and am limited enough to not be able to imagine for myself). >> While I am bothering you good people with my silly questions, I >>might just as well tack on another: if one invokes .executemany with a >>seq_of_parameters that is empty (like >> >>a_cursor.executemany(SQL, []) >> >>) shouldn't the interface module execute the query zero times, ie, not >>execute the query at all? >> >> > >Yes, executemany() with an empty sequence is a no-op. > > > Thank you all, Arthur Protin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20061219/efe3adfd/attachment.html From carsten at uniqsys.com Tue Dec 19 16:55:29 2006 From: carsten at uniqsys.com (Carsten Haese) Date: Tue, 19 Dec 2006 10:55:29 -0500 Subject: [DB-SIG] Clarification of cursor.arraysize In-Reply-To: <45880512.3030602@research.att.com> References: <45870E8C.4000404@research.att.com> <1166488006.3297.3.camel@localhost.localdomain> <45880512.3030602@research.att.com> Message-ID: <1166543729.3343.24.camel@dot.uniqsys.com> On Tue, 2006-12-19 at 10:28 -0500, Art Protin wrote: > I am probably being dense here, but ... This seems to be like saying > "The implementor is free to transfer parameters for .executemany() in > groups of 17, or not." Why mention it at all? It's an implementation hint. Take it or leave it. > Did someone write an interface that did tie the value for the number > of rows to transfer to the value for the number of sets of parameters > to transfer? I suspect that some piece of the historical debate in > developing this specification may have been lost here. Anecdotal evidence from http://mail.python.org/pipermail/db-sig/2003-March/003294.html suggests that cx_Oracle at some time referred to arraysize in executemany(), but I don't have any insight into the code to confirm or deny this. > I think that either the specification should omit that last line or > include enough additional information to permit the reader to see not > only how they can be linked (actually that IS simple enough to be left > out) but a reason why an implementation might benefit from having them > linked (which I still have not heard and am limited enough to not be > able to imagine for myself). There is no inherent benefit in "linking" executemany() and arraysize, except when the underlying API allows passing multiple parameter sets in bulk, thus reducing the number of communication round-trips. If such an optimization is possible, you need to know how many parameter sets to pass in each batch, and looking at the arraysize seems like an obvious thing to do. If such bulk execution is not possible, feel free to interact with the database one parameter tuple at a time. Hope this helps, Carsten. From mumatony-work at yahoo.com Thu Dec 21 10:33:38 2006 From: mumatony-work at yahoo.com (Boeing) Date: Thu, 21 Dec 2006 01:33:38 -0800 (PST) Subject: [DB-SIG] Python Script to run an Oralce select statement and return the value in HTML Message-ID: <655233.35596.qm@web31803.mail.mud.yahoo.com> Hi all; [Vickie thanks for your sample command line script http://d0db.fnal.gov/d0db/query.py.txt] I need help [I?m not a developer] but I need a python script hosted on an windows 2003 server which will query a remote Oracle database [odbc connection established] either using Oracle 9.2 or cx_Oracle [both installed on the server] but return the value of the query in an html [web - URL] page, Username; password and database will be hard coded in the script on the server, script code will not be displayed to end user. Its a simple select statement returning a html page in rows. Eventually SSL is going to be implemented. I have been able to get the command line py script to work [Vickie White's]. But not calling it through IIS 6. I get this error: CGI Error: The specified CGI application misbehaved by not returning a complete set of HTTP headers. But the python extension has been ?Allowed? in IIS and a simple "Hello World" python script works. [[ i.e. not real URLs: http://metatest.web.mycompany.com/cgi-bin/helloworld.py]] Failing: http://metatest.web.mycompany.com/cgi-bin/or3.py Sample for what I?ve gathered so far.. #!/usr/bin/python print "Content-type: text/html\n\n"; print ""; } } import cx_Oracle } } def connect(): username = "typeUserNameHere" [hard coded] password = "typePassHere" [hard coded] database = "typeDataBaseHere" [hard coded] } Query: } } "select * from MIR_SYSTEM_VERSION" Any ideas or help [sample code] would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20061221/1ce4dc72/attachment.html From ccurvey at gmail.com Thu Dec 21 12:32:01 2006 From: ccurvey at gmail.com (Chris Curvey) Date: Thu, 21 Dec 2006 06:32:01 -0500 Subject: [DB-SIG] Python Script to run an Oralce select statement and return the value in HTML In-Reply-To: <655233.35596.qm@web31803.mail.mud.yahoo.com> References: <655233.35596.qm@web31803.mail.mud.yahoo.com> Message-ID: <25ef693e0612210332m51e76b18hc7033d698c35749a@mail.gmail.com> I would start by adding import cgitb; cgitb.enable() at the top of your script. Since "hello world" seems to work, and you can get the script to run via the command line, there's probably something different about the environment that IIS is using to execute your script. (99% of the time, I find that it's a permissions problem.) Hope this helps! On 12/21/06, Boeing wrote: > > Hi all; [Vickie thanks for your sample command line script > http://d0db.fnal.gov/d0db/query.py.txt] > > I need help [I'm not a developer] but I need a python script hosted on an > windows 2003 server which will query a remote Oracle database [odbc > connection established] either using Oracle 9.2 or cx_Oracle [both > installed on the server] but return the value of the query in an html [web - > URL] page, Username; password and database will be hard coded in the script > on the server, script code will not be displayed to end user. Its a simple > select statement returning a html page in rows. Eventually SSL is going to > be implemented. > > I have been able to get the command line py script to work [Vickie > White's]. But not calling it through IIS 6. I get this error: CGI Error: > The specified CGI application misbehaved by not returning a complete set of > HTTP headers. But the python extension has been "Allowed" in IIS and a > simple "Hello World" python script works. [[ i.e. not real URLs: > http://metatest.web.mycompany.com/cgi-bin/helloworld.py]] > Failing: http://metatest.web.mycompany.com/cgi-bin/or3.py > > Sample for what I've gathered so far.. > > #!/usr/bin/python > print "Content-type: text/html\n\n"; > print ""; > } > } > import cx_Oracle > } > } > def connect(): > > username = "typeUserNameHere" [hard coded] > password = "typePassHere" [hard coded] > database = "typeDataBaseHere" [hard coded] > } > Query: > } > } > "select * from MIR_SYSTEM_VERSION" > > Any ideas or help [sample code] would be appreciated. > > _______________________________________________ > DB-SIG maillist - DB-SIG at python.org > http://mail.python.org/mailman/listinfo/db-sig > > > -- I am often wrong, but I am never in doubt. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20061221/f166137e/attachment.htm