From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 11:13:18 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:18 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:18 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Jan 13 11:13:18 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Jan 13 11:13:18 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:18 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:18 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 15:13:50 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:50 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:50 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Jan 13 15:13:50 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Jan 13 15:13:50 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0001.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:50 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:50 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 15:21:13 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:13 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:13 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Jan 13 15:21:13 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Jan 13 15:21:13 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0002.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:13 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:13 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 16:00:45 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:45 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:45 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Jan 13 16:00:45 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Jan 13 16:00:45 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0003.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:45 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:45 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 20:01:32 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:32 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:32 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Jan 13 20:01:32 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Jan 13 20:01:32 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0004.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:32 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:32 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 14 08:02:13 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:13 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:13 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Jan 14 08:02:13 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Jan 14 08:02:13 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0005.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:13 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:13 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 14 12:00:42 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:42 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:42 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Jan 14 12:00:42 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Jan 14 12:00:42 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0006.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:42 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:42 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 14 16:00:42 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:42 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:42 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Jan 14 16:00:42 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Jan 14 16:00:42 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0007.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:42 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:42 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 14 20:00:38 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:38 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:38 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Jan 14 20:00:38 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Jan 14 20:00:38 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0008.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:38 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:38 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 15 08:02:03 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:03 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:03 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Jan 15 08:02:03 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Jan 15 08:02:03 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0009.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:03 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:03 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 15 12:00:48 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:48 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:48 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Jan 15 12:00:48 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Jan 15 12:00:48 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0010.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:48 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:48 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 15 16:00:41 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:41 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:41 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Jan 15 16:00:41 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Jan 15 16:00:41 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0011.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:41 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:41 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 15 20:00:38 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:38 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:38 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Jan 15 20:00:38 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Jan 15 20:00:38 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0012.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:38 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:38 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 16 08:02:26 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:26 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:26 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Jan 16 08:02:26 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Jan 16 08:02:26 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0013.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:26 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:26 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 16 12:00:45 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:45 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:45 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Jan 16 12:00:45 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Jan 16 12:00:45 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0014.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:45 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:45 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 16 16:00:45 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:45 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:45 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Jan 16 16:00:45 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Jan 16 16:00:45 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0015.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:45 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:45 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 16 20:00:39 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:40 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:40 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Jan 16 20:00:40 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Jan 16 20:00:40 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0016.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:40 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:40 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 17 08:02:28 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:28 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:28 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Jan 17 08:02:28 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Jan 17 08:02:28 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0017.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:28 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:28 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 17 12:00:54 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:54 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:54 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Jan 17 12:00:54 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Jan 17 12:00:54 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0018.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:54 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:55 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 17 16:00:46 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:46 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:46 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Jan 17 16:00:46 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Jan 17 16:00:46 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0019.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:46 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:46 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 17 20:00:48 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:48 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:48 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Jan 17 20:00:48 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Jan 17 20:00:48 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0020.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:48 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:48 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 18 08:04:10 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:10 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:11 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Jan 18 08:04:11 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Jan 18 08:04:11 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0021.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:11 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:11 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 18 12:00:59 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:59 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:59 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Jan 18 12:00:59 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Jan 18 12:00:59 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0022.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:59 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:59 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 18 16:01:22 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:22 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:22 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Jan 18 16:01:22 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Jan 18 16:01:22 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0023.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:22 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:22 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 18 20:00:48 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:48 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:48 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Jan 18 20:00:48 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Jan 18 20:00:48 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0024.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:48 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:48 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 19 08:04:32 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:32 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:32 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Jan 19 08:04:32 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Jan 19 08:04:32 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0025.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:32 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:32 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 19 12:00:57 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:57 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:57 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Jan 19 12:00:57 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Jan 19 12:00:57 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0026.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:57 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:57 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 19 16:02:42 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:42 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:42 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Jan 19 16:02:42 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Jan 19 16:02:42 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0027.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:42 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:42 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 19 20:00:44 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:44 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:44 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Jan 19 20:00:44 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Jan 19 20:00:44 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0028.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:44 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:44 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 20 08:06:27 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:27 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:27 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Jan 20 08:06:28 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Jan 20 08:06:28 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0029.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:28 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:28 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 20 12:01:54 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:54 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:54 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Jan 20 12:01:54 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Jan 20 12:01:54 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0030.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:54 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:54 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 20 16:00:48 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:49 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:49 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Jan 20 16:00:49 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Jan 20 16:00:49 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0031.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:49 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:49 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 20 20:00:44 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:44 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:44 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Jan 20 20:00:44 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Jan 20 20:00:44 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0032.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:44 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:44 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 21 08:03:46 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:46 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:46 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Jan 21 08:03:46 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Jan 21 08:03:46 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0033.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:46 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:46 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 21 12:00:58 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:58 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:58 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Jan 21 12:00:58 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Jan 21 12:00:58 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0034.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:58 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:58 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 21 16:00:48 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:48 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:48 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Jan 21 16:00:48 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Jan 21 16:00:48 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0035.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:48 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:48 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 21 20:00:47 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:47 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:47 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Jan 21 20:00:47 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Jan 21 20:00:47 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0036.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:47 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:47 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 22 08:02:39 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:39 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:39 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Jan 22 08:02:39 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Jan 22 08:02:39 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0037.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:39 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:39 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 22 12:00:48 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:48 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:48 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Jan 22 12:00:48 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Jan 22 12:00:48 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0038.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:48 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:48 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 22 16:01:12 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:12 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:12 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Jan 22 16:01:12 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Jan 22 16:01:12 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0039.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:12 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:12 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 22 20:01:09 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:09 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:09 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Jan 22 20:01:09 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Jan 22 20:01:09 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0040.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:09 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:09 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 23 08:02:31 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:31 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:31 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Jan 23 08:02:31 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Jan 23 08:02:31 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0041.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:31 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:31 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 23 12:00:50 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:50 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:50 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Jan 23 12:00:50 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Jan 23 12:00:50 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0042.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:50 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:50 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 23 16:01:38 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:38 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:38 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Jan 23 16:01:38 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Jan 23 16:01:38 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0043.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:38 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:38 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 23 20:00:48 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:48 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:48 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Jan 23 20:00:48 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Jan 23 20:00:48 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0044.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:48 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:48 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 24 08:03:03 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:03 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:03 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Jan 24 08:03:03 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Jan 24 08:03:03 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0045.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:03 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:03 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 24 12:02:39 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:40 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:40 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Jan 24 12:02:40 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Jan 24 12:02:40 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0046.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:40 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:40 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 24 16:01:15 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:15 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:15 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Jan 24 16:01:16 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Jan 24 16:01:16 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0047.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:16 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:16 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 24 20:01:48 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:48 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:48 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Jan 24 20:01:48 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Jan 24 20:01:48 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0048.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:48 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:48 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 25 08:01:56 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:56 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:56 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Jan 25 08:01:56 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Jan 25 08:01:56 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0049.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:56 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:56 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 25 12:00:58 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:58 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:58 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Jan 25 12:00:58 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Jan 25 12:00:58 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0050.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:58 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:58 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 25 16:00:57 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:57 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:57 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Jan 25 16:00:57 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Jan 25 16:00:57 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0051.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:57 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:57 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 25 20:00:51 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:51 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:51 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Jan 25 20:00:51 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Jan 25 20:00:51 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0052.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:51 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:51 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 26 08:05:23 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:23 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:23 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Jan 26 08:05:23 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Jan 26 08:05:23 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0053.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:23 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:23 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 26 12:01:01 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:01 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:01 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Jan 26 12:01:01 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Jan 26 12:01:01 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0054.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:01 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:01 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 26 16:00:50 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:50 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:50 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Jan 26 16:00:50 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Jan 26 16:00:50 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0055.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:50 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:50 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 26 20:00:44 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:44 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:44 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Jan 26 20:00:44 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Jan 26 20:00:44 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0056.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:44 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:44 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 27 08:06:18 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:18 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:18 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Jan 27 08:06:18 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Jan 27 08:06:18 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0057.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:18 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:18 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 27 12:02:04 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:04 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:04 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Jan 27 12:02:04 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Jan 27 12:02:04 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0058.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:05 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:05 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 27 16:01:00 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:00 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:00 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Jan 27 16:01:00 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Jan 27 16:01:00 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0059.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:00 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:00 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 27 20:00:52 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:52 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:52 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Jan 27 20:00:52 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Jan 27 20:00:52 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0060.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:52 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:52 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 28 08:05:25 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:25 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:25 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Jan 28 08:05:25 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Jan 28 08:05:25 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0061.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:25 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:25 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 28 12:01:50 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:50 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:50 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Jan 28 12:01:50 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Jan 28 12:01:50 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0062.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:50 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:50 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 28 16:00:51 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:51 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:51 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Jan 28 16:00:51 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Jan 28 16:00:51 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0063.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:51 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:51 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 28 20:00:51 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:51 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:51 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Jan 28 20:00:51 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Jan 28 20:00:51 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0064.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:51 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:51 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 29 08:07:15 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:15 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:15 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Jan 29 08:07:15 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Jan 29 08:07:15 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0065.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:15 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:15 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 29 12:00:57 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:57 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:57 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Jan 29 12:00:57 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Jan 29 12:00:57 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0066.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:57 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:57 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 29 16:00:51 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:51 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:51 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Jan 29 16:00:51 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Jan 29 16:00:51 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0067.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:51 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:51 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 29 20:00:52 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:52 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:52 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Jan 29 20:00:52 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Jan 29 20:00:52 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0068.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:52 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:52 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 30 08:08:04 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:04 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:04 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Jan 30 08:08:04 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Jan 30 08:08:04 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0069.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:04 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:04 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 30 12:03:46 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:46 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:46 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Jan 30 12:03:46 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Jan 30 12:03:46 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0070.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:46 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:46 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 30 16:03:59 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:59 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:59 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Jan 30 16:03:59 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Jan 30 16:04:00 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0071.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:00 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:00 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 30 20:02:06 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:06 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:06 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Jan 30 20:02:06 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Jan 30 20:02:06 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0072.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:06 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:06 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 31 08:07:38 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:38 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:38 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Jan 31 08:07:38 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Jan 31 08:07:38 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0073.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:38 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:38 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 31 12:04:07 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:07 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:07 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Jan 31 12:04:07 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Jan 31 12:04:07 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0074.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:07 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:07 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 31 16:02:09 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:09 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:09 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Jan 31 16:02:09 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Jan 31 16:02:10 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0075.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:10 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:10 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 31 20:01:02 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:02 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:02 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Jan 31 20:01:02 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Jan 31 20:01:02 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0076.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:02 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:02 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 1 08:09:20 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:20 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:20 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Feb 1 08:09:20 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Feb 1 08:09:20 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0077.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:20 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:20 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 1 12:02:34 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:35 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:35 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Feb 1 12:02:35 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Feb 1 12:02:35 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0078.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:36 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:36 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 1 16:00:58 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:58 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:58 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Feb 1 16:00:58 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Feb 1 16:00:58 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0079.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:58 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:58 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 1 20:00:56 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:56 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:56 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Feb 1 20:00:56 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Feb 1 20:00:56 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0080.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:56 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:56 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 2 08:11:47 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:47 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:47 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Feb 2 08:11:47 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Feb 2 08:11:47 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0081.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:47 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:47 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 2 12:02:40 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:40 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:40 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Feb 2 12:02:40 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Feb 2 12:02:41 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0082.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:41 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:41 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 2 16:01:06 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:06 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:06 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Feb 2 16:01:06 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Feb 2 16:01:06 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0083.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:06 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:06 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 2 20:00:56 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:56 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:56 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Feb 2 20:00:56 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Feb 2 20:00:56 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0084.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:56 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:56 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 3 08:11:28 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:11:29 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:11:29 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Feb 3 08:11:29 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Feb 3 08:11:29 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0085.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:11:29 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:11:29 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 3 12:02:30 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:30 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:30 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Feb 3 12:02:30 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Feb 3 12:02:30 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0086.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:30 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:30 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 3 16:00:53 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:54 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:54 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Feb 3 16:00:54 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Feb 3 16:00:54 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0087.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:54 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:54 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 3 20:00:58 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:58 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:58 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Feb 3 20:00:58 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Feb 3 20:00:58 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0088.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:58 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:58 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 4 08:07:17 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:17 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:17 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Feb 4 08:07:17 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Feb 4 08:07:17 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0089.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:17 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:17 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 4 12:02:32 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:32 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:32 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Feb 4 12:02:32 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Feb 4 12:02:32 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0090.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:33 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:33 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 4 16:01:08 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:08 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:08 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Feb 4 16:01:08 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Feb 4 16:01:08 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0091.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:08 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:08 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 4 20:00:59 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:59 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:59 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Feb 4 20:00:59 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Feb 4 20:00:59 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0092.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:00 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:00 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 5 08:07:34 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:34 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:34 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Feb 5 08:07:34 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Feb 5 08:07:35 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0093.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:35 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:35 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 5 12:02:34 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:34 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:34 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Feb 5 12:02:34 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Feb 5 12:02:35 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0094.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:35 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:35 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 5 16:01:03 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:03 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:03 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Feb 5 16:01:03 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Feb 5 16:01:03 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0095.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:03 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:03 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 5 20:00:56 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:56 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:56 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Feb 5 20:00:56 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Feb 5 20:00:56 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0096.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:56 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:56 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 6 08:13:27 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:13:27 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:13:27 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Feb 6 08:13:27 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Feb 6 08:13:29 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0097.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:13:29 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:13:29 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 6 12:02:32 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:32 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:32 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Feb 6 12:02:32 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Feb 6 12:02:32 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0098.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:32 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:32 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 6 16:01:02 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:02 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:02 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Feb 6 16:01:02 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Feb 6 16:01:02 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0099.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:02 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:02 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 6 20:00:57 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:57 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:57 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Feb 6 20:00:57 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Feb 6 20:00:57 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0100.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:57 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:57 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 7 08:21:03 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:21:04 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:21:04 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Feb 7 08:21:04 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Feb 7 08:21:06 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0101.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:21:06 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:21:06 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 7 12:03:07 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:08 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:08 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Feb 7 12:03:08 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Feb 7 12:03:08 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0102.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:08 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:08 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 7 16:01:05 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:05 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:05 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Feb 7 16:01:05 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Feb 7 16:01:05 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0103.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:05 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:05 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 7 20:01:01 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:01 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:01 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Feb 7 20:01:01 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Feb 7 20:01:01 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0104.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:01 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:01 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 8 08:21:00 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:21:00 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:21:00 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Feb 8 08:21:00 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Feb 8 08:21:00 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0105.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:21:00 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:21:01 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 8 12:03:01 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:01 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:01 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Feb 8 12:03:01 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Feb 8 12:03:02 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0106.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:02 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:02 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 8 16:01:09 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:09 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:09 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Feb 8 16:01:09 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Feb 8 16:01:09 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0107.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:09 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:09 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 8 20:00:58 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:58 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:58 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Feb 8 20:00:58 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Feb 8 20:00:58 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0108.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:58 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:58 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 9 08:08:37 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:38 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:38 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Feb 9 08:08:38 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Feb 9 08:08:38 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0109.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:38 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:38 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 9 12:02:50 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:50 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:50 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Feb 9 12:02:50 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Feb 9 12:02:50 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0110.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:50 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:50 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 9 16:01:10 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:10 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:10 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Feb 9 16:01:10 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Feb 9 16:01:10 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0111.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:10 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:10 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 9 20:01:03 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:03 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:04 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Feb 9 20:01:04 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Feb 9 20:01:04 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0112.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:04 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:04 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 10 08:17:59 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:18:00 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:18:00 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Feb 10 08:18:00 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Feb 10 08:18:01 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0113.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:18:01 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:18:02 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 10 12:03:27 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:27 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:27 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Feb 10 12:03:27 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Feb 10 12:03:28 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0114.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:28 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:28 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 10 16:01:03 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:03 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:03 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Feb 10 16:01:03 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Feb 10 16:01:03 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0115.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:03 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:03 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 10 20:01:08 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:09 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:09 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Feb 10 20:01:09 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Feb 10 20:01:09 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0116.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:09 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:09 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 11 08:12:24 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:24 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:24 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Feb 11 08:12:24 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Feb 11 08:12:24 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0117.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:25 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:25 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 11 12:02:29 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:29 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:29 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Feb 11 12:02:29 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Feb 11 12:02:29 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0118.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:29 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:29 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 11 16:01:00 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:00 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:00 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Feb 11 16:01:00 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Feb 11 16:01:00 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0119.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:00 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:00 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 11 20:00:54 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:54 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:54 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sat Feb 11 20:00:54 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sat Feb 11 20:00:54 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0120.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:54 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:54 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 12 08:08:49 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:49 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:49 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Feb 12 08:08:49 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Feb 12 08:08:50 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0121.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:50 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:50 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 12 12:02:37 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:37 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:37 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Feb 12 12:02:37 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Feb 12 12:02:37 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0122.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:37 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:37 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 12 16:01:04 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:04 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:04 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Feb 12 16:01:04 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Feb 12 16:01:04 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0123.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:04 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:04 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 12 20:00:58 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:58 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:58 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Sun Feb 12 20:00:58 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Sun Feb 12 20:00:58 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0124.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:58 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:58 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 13 08:16:14 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:14 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:14 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Feb 13 08:16:15 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Feb 13 08:16:15 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0125.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:15 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:15 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 13 12:02:54 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:54 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:54 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Feb 13 12:02:54 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Feb 13 12:02:55 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0126.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:55 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:55 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 13 16:01:16 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:16 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:16 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Feb 13 16:01:16 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Feb 13 16:01:16 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0127.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:16 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:16 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 13 20:00:58 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:58 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:58 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Mon Feb 13 20:00:58 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Mon Feb 13 20:00:58 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0128.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:58 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:58 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 14 08:18:16 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:18:17 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:18:17 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Feb 14 08:18:17 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Feb 14 08:18:18 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0129.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:18:18 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:18:18 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 14 12:03:12 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:12 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:12 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Feb 14 12:03:12 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Feb 14 12:03:12 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0130.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:12 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:12 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 14 16:01:21 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:21 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:21 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Feb 14 16:01:21 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Feb 14 16:01:21 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0131.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:21 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:21 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 14 20:01:03 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:03 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:03 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Tue Feb 14 20:01:03 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Tue Feb 14 20:01:03 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0132.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:03 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:03 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 08:25:26 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:25:26 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:25:26 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Feb 15 08:25:27 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Feb 15 08:25:31 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0133.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:25:31 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:25:31 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 12:05:04 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:04 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:04 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Feb 15 12:05:04 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Feb 15 12:05:04 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0134.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:04 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:04 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 16:01:27 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:27 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:27 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Feb 15 16:01:27 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Feb 15 16:01:27 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0135.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:27 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:27 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 19:27:59 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:59 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:59 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Feb 15 19:27:59 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Feb 15 19:27:59 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0136.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:59 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:59 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 20:12:52 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:55 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:55 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Wed Feb 15 20:12:55 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Wed Feb 15 20:12:55 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0137.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:55 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:55 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 16 08:44:28 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:44:29 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:44:30 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Thu Feb 16 08:44:30 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Thu Feb 16 08:44:32 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0138.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:44:32 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:44:32 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From Jim.Vickroy at noaa.gov Wed Feb 19 11:07:19 2003 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Mar 31 16:33:27 2006 Subject: [egenix-users] SQL Server query result as XML Message-ID: <3E53C7D6.6F9692DD@noaa.gov> Hello, I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. Here is the result of asking SQL Server to formulate a query result as XML: >>> cur.execute('select * from employee for xml auto') Traceback (most recent call last): File "", line 1, in ? Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 2394) The above SQL query works fine from MS SQL QueryAnalyzer. Any ideas why it does not work from Python? Thanks, -- jv From mal at lemburg.com Fri Feb 28 22:00:08 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:27 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter, Version 1.0.0 Message-ID: <3E5FCDD8.1040609@lemburg.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.0 (for Zope 2.5 and 2.6) ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98/95, Linux and Solaris using the same interface on all platforms. The mxODBC Zope DA implements thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better performance than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in Zope Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://www.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:33:32 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:27 2006 Subject: [egenix-users] SQL Server query result as XML In-Reply-To: <3E53C7D6.6F9692DD@noaa.gov> References: <3E53C7D6.6F9692DD@noaa.gov> Message-ID: <3E5FD5AC.40705@lemburg.com> Jim Vickroy wrote: > Hello, > > I'm using mx.ODBC.Windows with Python 2.2.2 on a Windows 2000 machine. > > Here is the result of asking SQL Server to formulate a query result as > XML: > > >>>>cur.execute('select * from employee for xml auto') > > Traceback (most recent call last): > File "", line 1, in ? > Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]String data, > right truncation', 2394) > > > The above SQL query works fine from MS SQL QueryAnalyzer. > > Any ideas why it does not work from Python? This is a warning that's probably related to the column name length. The maximum column name length is set to 37 in mxODBC (because that's what SQL defines as limit). You can work around this by explicitly naming the columns in the SQL statement. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From paul.rensing at att.net Mon Feb 3 17:34:22 2003 From: paul.rensing at att.net (Paul Rensing) Date: Fri Mar 31 16:33:27 2006 Subject: [egenix-users] Bug in DateTime parsing Message-ID: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Hi Everyone, I am not subscribed to the list, so please reply directly. I did not see a bug reporting address on the Web site, so I thought I would start here. There is a bug in the latest version of DateTime when parsing times containing "AM" or "PM". Specifically, if the time is "12:??AM" or "12:??PM", the resulting time is off by 12 hours (actually, it fails on "12:??PM"). The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the hour when it sees "PM". This not correct when the hour is "12". Paul -- Paul Rensing From tommi.auvinen at wicom.com Fri Feb 21 10:18:40 2003 From: tommi.auvinen at wicom.com (Tommi Auvinen) Date: Fri Mar 31 16:33:27 2006 Subject: [egenix-users] mxODBC and Python interpreter lock Message-ID: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Hello. There are quite many calls to Windows ODBC library (mxODBC for Python 1.5) that are not freeing the Python lock (for performance reasons, I guess), and now I have a strong feeling that one or more of those call do access (in some special cases?) the SQL Server, and if the SQL Server is _really_ occupied (in fact, other instance of SQL Server hogged it all) the Python interpreter is locked for a long time. 150 msec lock is the best I have managed to reproduce in my tests, but in "real life" there are some cases where the locking time has been tens of seconds. Is there any risk in compiling my own version where all the calls to ODBC driver API do release the lock (so is performance the only reason not to free the lock always, or are there other caveats)? R:TAU -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20030221/d9b2590b/attachment-0139.htm From mal at lemburg.com Fri Feb 28 22:51:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:27 2006 Subject: [egenix-users] Bug in DateTime parsing In-Reply-To: <1044293652.1457.47.camel@opus.cimetricsinternal.com> References: <1044293652.1457.47.camel@opus.cimetricsinternal.com> Message-ID: <3E5FD9FC.8050006@lemburg.com> Paul Rensing wrote: > Hi Everyone, > > I am not subscribed to the list, so please reply directly. > > I did not see a bug reporting address on the Web site, so I thought I > would start here. > > There is a bug in the latest version of DateTime when parsing times > containing "AM" or "PM". Specifically, if the time is "12:??AM" or > "12:??PM", the resulting time is off by 12 hours (actually, it fails on > "12:??PM"). > > The problem is that "12:00AM" means "0:00" (in a 24-hour clock) and > "12:00PM" means "12:00". The code just ignores "AM" and add 12 to the > hour when it sees "PM". This not correct when the hour is "12". This bug will be fixed in the upcoming egenix-mx-base release 2.1.0 (sometime in March). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left From mal at lemburg.com Fri Feb 28 22:55:55 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:27 2006 Subject: [egenix-users] mxODBC and Python interpreter lock In-Reply-To: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> References: <53404C1181500348B8F07B400D418EB15A7069@postman.wicom.com> Message-ID: <3E5FDAEB.8010306@lemburg.com> Tommi Auvinen wrote: > Hello. > > There are quite many calls to Windows ODBC library (mxODBC for Python > 1.5) that are not freeing the Python lock (for performance reasons, I > guess), and now I have a strong feeling that one or more of those call > do access (in some special cases?) the SQL Server, and if the SQL Server > is _really_ occupied (in fact, other instance of SQL Server hogged it > all) the Python interpreter is locked for a long time. 150 msec lock is > the best I have managed to reproduce in my tests, but in "real life" > there are some cases where the locking time has been tens of seconds. > > Is there any risk in compiling my own version where all the calls to > ODBC driver API do release the lock (so is performance the only reason > not to free the lock always, or are there other caveats)? Only the query APIs currently free the lock. Which other APIs do you think would also benefit from this ? Note that you can't free the lock at arbitrary times since this could introduce problems with callback etc. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left